Firebase Data Connect सेवा के तीन मुख्य कॉम्पोनेंट होते हैं:
- अपना SQL स्कीमा वाला, कोई PostgreSQL डेटाबेस
- Data Connect ऐप्लिकेशन स्कीमा (आपकी
.gql
फ़ाइलों में बताया गया) - कई कनेक्टर (आपकी
.gql
फ़ाइलों में बताए गए,connector.yaml
फ़ाइलों में कॉन्फ़िगर किए गए).
एसक्यूएल स्कीमा, आपके डेटा का सोर्स ऑफ़ ट्रूथ होता है. Data Connectस्कीमा से यह तय होता है कि आपके कनेक्टर उस डेटा को कैसे देख सकते हैं. साथ ही, कनेक्टर उन एपीआई के बारे में बताते हैं जिनका इस्तेमाल आपके क्लाइंट उस डेटा को ऐक्सेस करने के लिए कर सकते हैं.
सीएलआई की मदद से Data Connect सेवा को डिप्लॉय करने पर, आपको अपने SQL स्कीमा को माइग्रेट करना होगा. इसके बाद, Data Connect स्कीमा को अपडेट करना होगा और फिर अपने हर कनेक्टर को अपडेट करना होगा.
डिप्लॉयमेंट से जुड़े अहम कॉन्सेप्ट
डिप्लॉयमेंट को पूरी तरह से समझने के लिए, स्कीमा और कनेक्टर के बारे में ज़रूरी कॉन्सेप्ट को ध्यान में रखना ज़रूरी है.
स्कीमा डिप्लॉयमेंट
Data Connect स्कीमा को डिप्लॉय करने से, आपके Cloud SQL डेटाबेस के SQL स्कीमा पर असर पड़ता है. Data Connect, डिप्लॉयमेंट के दौरान स्कीमा को माइग्रेट करने में आपकी मदद करता है. भले ही, आप किसी नए डेटाबेस के साथ काम कर रहे हों या किसी मौजूदा डेटाबेस में बिना किसी नुकसान के बदलाव करना हो.
Data Connect स्कीमा माइग्रेशन में, स्कीमा की पुष्टि करने के दो अलग-अलग मोड होते हैं: स्ट्रिक्ट और कंपैटबल.
सख्त मोड में पुष्टि करने के लिए ज़रूरी है कि ऐप्लिकेशन स्कीमा को अपडेट करने से पहले, डेटाबेस स्कीमा सटीक तौर पर ऐप्लिकेशन स्कीमा से मैच करता हो. आपके Data Connect स्कीमा में इस्तेमाल नहीं की गई टेबल या कॉलम, डेटाबेस से मिटा दिए जाएंगे.
साथ काम करने वाले मोड की पुष्टि करने के लिए ज़रूरी है कि डेटाबेस स्कीमा, ऐप्लिकेशन स्कीमा के साथ काम करता हो. इसके बाद ही, ऐप्लिकेशन स्कीमा को अपडेट किया जा सकता है. स्कीमा, टेबल या कॉलम को हटाने वाले अन्य बदलाव करना ज़रूरी नहीं है.
काम करने का मतलब है कि स्कीमा माइग्रेशन का असर सिर्फ़ आपके ऐप्लिकेशन स्कीमा में रेफ़र की गई टेबल और कॉलम पर पड़ता है. आपके डेटाबेस में मौजूद ऐसे एलिमेंट जिनका इस्तेमाल आपके ऐप्लिकेशन स्कीमा में नहीं किया जाता है उन्हें बिना बदलाव के छोड़ दिया जाता है. इसलिए, डिप्लॉयमेंट के बाद, आपके डेटाबेस में ये आइटम शामिल हो सकते हैं:
- स्कीमा
- टेबल
- कॉलम
कनेक्टर डिप्लॉयमेंट
Data Connect क्वेरी और म्यूटेशन, क्लाइंट कोड से सबमिट नहीं किए जाते और सर्वर पर लागू नहीं किए जाते. इसके बजाय, डिप्लॉय होने पर, ये Data Connect ऑपरेशन Cloud Functions की तरह सर्वर पर सेव किए जाते हैं. इसका मतलब है कि डिप्लॉयमेंट से, मौजूदा उपयोगकर्ताओं को समस्याएं आ सकती हैं.
Data Connect, आपके कनेक्टर अपडेट में होने वाले बदलावों का विश्लेषण, Firebase सीएलआई में इंटिग्रेट करता है.
सीएलआई, आपके स्कीमा के हिसाब से हर कनेक्टर में हुए बदलावों का विश्लेषण करता है. साथ ही, कनेक्टर में हुए ऐसे बदलावों के लिए आकलन मैसेज का एक सेट जारी करता है जिनसे क्लाइंट के व्यवहार में बदलाव हो सकता है (मैसेज चेतावनी के लेवल पर होते हैं) या क्लाइंट कोड के पिछले वर्शन काम नहीं कर सकते या काम करना बंद कर सकते हैं (मैसेज ब्रेकिंग-लेवल पर होते हैं).
उदाहरण के लिए:
- कनेक्टर में ऐसे बदलाव जिनसे क्लाइंट के व्यवहार में बदलाव हो सकता है. जैसे,
@retired
स्कीमा एनोटेशन के बिना, क्वेरी से वह फ़ील्ड हटाना जिसमें वैल्यू न होने की अनुमति है. - कनेक्टर में ऐसे बदलाव किए जा सकते हैं जिनसे क्लाइंट काम करना बंद कर सकते हैं या काम करना बंद कर देंगे. जैसे, बिना डिफ़ॉल्ट वैल्यू के, शून्य वैल्यू वाले ऑपरेशन वैरिएबल को शून्य वैल्यू वाले वैरिएबल में बदलना या किसी फ़ील्ड के डेटा टाइप को किसी ऐसे टाइप में बदलना जो काम नहीं करता (जैसे,
String
सेInt
).
चेतावनी-लेवल और ब्रेकिंग-लेवल की स्थितियों की ज़्यादा जानकारी, सीएलआई रेफ़रंस गाइड में दी गई है.
डिप्लॉयमेंट वर्कफ़्लो का पालन करना
Data Connect प्रोजेक्ट पर, स्थानीय प्रोजेक्ट डायरेक्ट्री और Firebase कंसोल, दोनों में काम किया जा सकता है.
डिप्लॉयमेंट के लिए सुझाए गए फ़्लो में ये शामिल हैं:
firebase dataconnect:services:list
की मदद से, फ़िलहाल डिप्लॉय किए गए स्कीमा और कनेक्टर की सूची बनाना.- स्कीमा के अपडेट को मैनेज करना.
firebase dataconnect:sql:diff
की मदद से, अपने Cloud SQL डेटाबेस और लोकल Data Connect स्कीमा के बीच SQL स्कीमा के अंतर की जांच करें.- अगर ज़रूरी हो, तो
dataconnect:sql:migrate
की मदद से एसक्यूएल स्कीमा माइग्रेशन करें.
firebase deploy
चलाकर, स्कीमा और कनेक्ट डिप्लॉयमेंट करना. ऐसा सिर्फ़ अपने स्कीमा, सिर्फ़ अपने कनेक्टर या संसाधनों के कॉम्बिनेशन के लिए किया जा सकता है.
Data Connect संसाधनों को डिप्लॉय और मैनेज करना
डिप्लॉयमेंट करने से पहले, प्रोडक्शन के संसाधनों की पुष्टि करना एक अच्छा तरीका है.
firebase dataconnect:services:list
किसी लोकल प्रोजेक्ट डायरेक्ट्री में काम करते समय, आम तौर पर इंटरैक्टिव सुझावों के साथ, अपने स्कीमा और कनेक्टर को प्रोडक्शन में डिप्लॉय करने के लिए, firebase deploy
कमांड का इस्तेमाल किया जाता है.
deploy
कमांड का इस्तेमाल करके, --only dataconnect
फ़्लैग की मदद से अपने प्रोजेक्ट में Data Connect डिप्लॉयमेंट को अन्य प्रॉडक्ट से अलग किया जा सकता है.
सामान्य डिप्लॉयमेंट
firebase deploy --only dataconnect
सामान्य डिप्लॉयमेंट में, Firebase CLI आपके स्कीमा और कनेक्टर को डिप्लॉय करने की कोशिश करता है.
इससे यह पुष्टि होती है कि नया स्कीमा, किसी भी मौजूदा कनेक्टर को काम करने से नहीं रोक रहा है. बड़े बदलाव करते समय, सबसे सही तरीके अपनाएं.
यह इस बात की भी पुष्टि करता है कि Data Connect स्कीमा को अपडेट करने से पहले, SQL स्कीमा पहले से ही माइग्रेट हो चुका है. अगर ऐसा नहीं है, तो स्कीमा माइग्रेट करने के लिए, ज़रूरी सभी चरणों के बारे में अपने-आप सूचना मिलेगी.
--force
फ़्लैग डिप्लॉयमेंट
firebase deploy --only dataconnect --force
अगर कनेक्टर या SQL स्कीमा की पुष्टि करने की कोई समस्या नहीं है, तो --force
के साथ कमांड को फिर से चलाकर, इन समस्याओं को अनदेखा किया जा सकता है.
--force
डिप्लॉय करने की सुविधा अब भी यह जांच करती है कि SQL स्कीमा,
Data Connect स्कीमा से मैच करता है या नहीं. साथ ही, यह सुविधा, स्कीमा के काम न करने की चेतावनी देती है और प्रॉम्प्ट दिखाती है.
चुने गए रिसॉर्स डिप्लॉय करना
ज़्यादा बारीकी से कंट्रोल करने के लिए, serviceId
आर्ग्युमेंट के साथ --only
फ़्लैग का इस्तेमाल करें. किसी खास सेवा के लिए सिर्फ़ स्कीमा में किए गए बदलावों को डिप्लॉय करने के लिए:
firebase deploy --only dataconnect:serviceId:schema
किसी खास कनेक्टर और सेवा के लिए भी सभी संसाधनों को डिप्लॉय किया जा सकता है.
firebase deploy --only dataconnect:serviceId:connectorId
आखिर में, किसी एक सेवा के लिए स्कीमा और सभी कनेक्टर को डिप्लॉय किया जा सकता है.
firebase deploy --only dataconnect:serviceId
किसी डिप्लॉयमेंट को रोल बैक करना
मैन्युअल रूप से रोलबैक करने के लिए, अपने कोड के पिछले वर्शन को देखें और उसे डिप्लॉय करें. अगर ओरिजनल डिप्लॉयमेंट में, डेटा को नुकसान पहुंचाने वाले बदलाव शामिल थे, तो हो सकता है कि मिटाए गए डेटा को पूरी तरह से वापस न लाया जा सके.
डेटाबेस स्कीमा माइग्रेट करना
अगर प्रोटोटाइप को तेज़ी से तैयार किया जा रहा है, स्कीमा के साथ प्रयोग किया जा रहा है, और आपको पता है कि स्कीमा में किए गए बदलाव नुकसान पहुंचा सकते हैं, तो बदलावों की पुष्टि करने और अपडेट करने के तरीके की निगरानी करने के लिए, Data Connect टूल का इस्तेमाल किया जा सकता है.
SQL स्कीमा में हुए बदलावों की तुलना करना
बदलावों की पुष्टि करने के लिए:
firebase dataconnect:sql:diff
सेवाओं की सूची को कॉमा लगाकर अलग किया जा सकता है.
यह कमांड, किसी सेवा के लोकल स्कीमा की तुलना, उससे जुड़े Cloud SQL डेटाबेस के मौजूदा स्कीमा से करता है. अगर कोई अंतर है, तो यह उन SQL निर्देशों को प्रिंट करता है जिन्हें उस अंतर को ठीक करने के लिए चलाया जाएगा
परिवर्तन लागू करें
जब आप स्कीमा के Cloud SQL इंस्टेंस में बदलावों को डिप्लॉय करने के लिए तैयार हों, तो firebase dataconnect:sql:migrate
कमांड जारी करें. आपको बदलावों को स्वीकार करने के लिए कहा जाएगा.
firebase dataconnect:sql:migrate [serviceId]
इंटरैक्टिव एनवायरमेंट में, एसक्यूएल माइग्रेशन स्टेटमेंट और ऐक्शन प्रॉम्प्ट दिखाए जाते हैं.
स्ट्रिक्ट या कंपैटबिलिटी मोड में माइग्रेट करना
किसी नए प्रोजेक्ट में, स्कीमा की पुष्टि करने का डिफ़ॉल्ट मोड लागू होता है. migrate
कमांड, डेटाबेस स्कीमा में वे सभी बदलाव लागू करता है जो आपके ऐप्लिकेशन स्कीमा के लिए ज़रूरी हैं. इसके बाद, आपको वैकल्पिक ऑपरेशन को मंज़ूरी देने के लिए कहा जाता है. ये ऑपरेशन, स्कीमा, टेबल या कॉलम को हटा देते हैं, ताकि आपके डेटाबेस स्कीमा को आपके ऐप्लिकेशन स्कीमा से पूरी तरह मैच कराया जा सके.
dataconnect.yaml
फ़ाइल में बदलाव करके, इस व्यवहार में बदलाव किया जा सकता है.
schemaValidation
कुंजी से टिप्पणी हटाएं और COMPATIBLE
का एलान करें, ताकि माइग्रेशन में सिर्फ़ ज़रूरी बदलाव लागू हों.
schemaValidation: "COMPATIBLE"
इसके अलावा, स्कीमा के व्यवहार को STRICT
पर सेट करें, ताकि स्कीमा में किए गए सभी बदलाव लागू हो जाएं और आपके डेटाबेस स्कीमा को आपके ऐप्लिकेशन स्कीमा से मैच करने के लिए मजबूर किया जा सके.
schemaValidation: "STRICT"
ज़्यादा जानकारी के लिए, Data Connect सीएलआई रेफ़रंस देखें.
कनेक्टर अपडेट करना
firebase deploy
को चलाने पर, सीएलआई लागू होने वाले कनेक्टर को अपडेट करना शुरू करता है. साथ ही, चेतावनी-लेवल (क्लाइंट के व्यवहार पर असर पड़ सकता है) और ब्रेकिंग-लेवल (संभवतः या निश्चित रूप से ब्रेकिंग) के आकलन के मैसेज जारी करता है.
सीएलआई की मदद से कनेक्टर के अपडेट मैनेज करना
इंटरैक्टिव मोड और नॉन-इंटरैक्टिव मोड में, सीएलआई का व्यवहार थोड़ा अलग होता है.
जैसा कि आपको उम्मीद होगी, इंटरैक्टिव मोड में सीएलआई, आपको सभी मैसेज स्वीकार करने के लिए कहता है. --force
फ़्लैग की मदद से, कनेक्टर को लागू करने की प्रक्रिया को बदला जा सकता है और उसे लागू करने के लिए मजबूर किया जा सकता है.
# Prompts for acceptance for any warning-level or breaking-level changes prior # to deploying connectors. firebase deploy --only dataconnect
# Will deploy connectors without prompting. firebase deploy --only dataconnect --force
नॉन-इंटरैक्टिव मोड में, सीएलआई आपके कनेक्टर को तब तक डिप्लॉय करेगा, जब तक कि ब्रेकिंग-लेवल के आकलन न हों. ऐसा न करने पर, आपकी स्क्रिप्ट, ब्रेकिंग बदलावों के लॉग के साथ बंद हो जाएगी. --force
फ़्लैग सेट करके, इसे बदला और डिप्लॉय किया जा सकता है.
# Will deploy connectors with warning-level changes. If any breaking changes # are present, the deploy will fail and output any breaking changes firebase deploy --only dataconnect --non-interactive
# Will deploy the connectors from the previous step, if the same issues are present. firebase deploy --only dataconnect --non-interactive --force
ज़्यादा जानकारी के लिए, सीएलआई की रेफ़रंस गाइड देखें.
स्कीमा और कनेक्टर को मैनेज करने के सबसे सही तरीके
Firebase, आपके Data Connect प्रोजेक्ट में अपनाए जाने वाले कुछ तरीकों का सुझाव देता है.
नुकसान पहुंचा सकने वाले बदलावों को कम करना
- Firebase का सुझाव है कि आप अपने Data Connect स्कीमा और कनेक्टर फ़ाइलों को सोर्स कंट्रोल में रखें.
- जब भी हो सके, तो बदलावों से बचें. ब्रेकिंग बदलावों के कुछ सामान्य उदाहरणों में ये शामिल हैं:
- अपने स्कीमा से कोई फ़ील्ड हटाना
- अपने स्कीमा में, वैल्यू न डालने की अनुमति वाले फ़ील्ड को वैल्यू डालने की अनुमति वाला फ़ील्ड बनाना (जैसे,
Int
->Int!
) - अपने स्कीमा में किसी फ़ील्ड का नाम बदलना.
- अगर आपको अपने स्कीमा से कोई फ़ील्ड हटाना है, तो असर को कम करने के लिए, इसे कुछ डिप्लॉयमेंट में बांटें:
- सबसे पहले, अपने कनेक्टर में फ़ील्ड के सभी रेफ़रंस हटाएं और बदलाव को डिप्लॉय करें.
- इसके बाद, नए जनरेट किए गए SDK टूल का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन अपडेट करें.
- आखिर में, अपने स्कीमा
.gql
फ़ाइल में फ़ील्ड हटाएं, अपने SQL स्कीमा को माइग्रेट करें, और फिर से डिप्लॉय करें.
नए डेटाबेस के साथ काम करते समय, स्ट्रिक्ट मोड का इस्तेमाल करना
अगर किसी नए डेटाबेस के साथ Data Connect का इस्तेमाल किया जा रहा है और आपके ऐप्लिकेशन स्कीमा को लगातार डेवलप किया जा रहा है, तो अपने dataconnect.yaml
में schemaValidation: "STRICT"
की जानकारी दी जा सकती है. इससे यह पक्का किया जा सकता है कि आपका डेटाबेस स्कीमा, ऐप्लिकेशन स्कीमा के हिसाब से हो.
इससे यह पक्का होगा कि वैकल्पिक बदलाव भी लागू हो जाएं.
अगर आपके डेटाबेस में प्रोडक्शन डेटा है, तो कम्पैटबिलिटी मोड का इस्तेमाल करें
अगर आपको किसी ऐसे डेटाबेस में बदलाव करने हैं जिसमें प्रोडक्शन डेटा शामिल है, तो हमारा सुझाव है कि आप स्कीमा माइग्रेशन को काम करने वाले मोड में चलाएं. इससे यह पक्का किया जा सकेगा कि मौजूदा डेटा नष्ट न हो. dataconnect.yaml
में schemaValidation: "COMPATIBLE"
का इस्तेमाल किया जा सकता है.
कंपैटबिलिटी मोड में, आपके डेटाबेस पर सिर्फ़ स्कीमा माइग्रेशन के ज़रूरी बदलाव लागू किए जाते हैं.
DROP SCHEMA
,DROP TABLE
, औरDROP COLUMN
को वैकल्पिक स्टेटमेंट माना जाता है. ये आपके प्लान के लिए जनरेट नहीं होंगे. भले ही, आपके डेटाबेस स्कीमा में ऐसे स्कीमा, टेबल या कॉलम शामिल हों जो आपके ऐप्लिकेशन स्कीमा में तय नहीं किए गए हैं.- अगर आपकी डेटाबेस टेबल में कोई ऐसा कॉलम है जो नॉन-शून्य है और आपके ऐप्लिकेशन स्कीमा में शामिल नहीं है, तो
NOT NULL
शर्त हटा दी जाएगी. इससे, तय किए गए कनेक्टर की मदद से, टेबल में अब भी डेटा जोड़ा जा सकेगा.
आगे क्या करना है?
- जनरेट किए गए SDK टूल की मदद से डेवलप किए गए क्लाइंट कोड को डिप्लॉय और मैनेज करने के बारे में, Android, iOS, वेब, और Flutter के लिए बनी गाइड में बताया गया है.
- डिप्लॉयमेंट टूल के बारे में ज़्यादा जानकारी के लिए, Data Connect सीएलआई रेफ़रंस और Data Connect कॉन्फ़िगरेशन फ़ाइल रेफ़रंस देखें.