Data Connect के स्कीमा और कनेक्टर डिप्लॉय और मैनेज करना

Firebase Data Connect सेवा के तीन मुख्य कॉम्पोनेंट होते हैं:

  • अपना SQL स्कीमा वाला, कोई PostgreSQL डेटाबेस
  • Data Connect ऐप्लिकेशन स्कीमा (आपकी .gql फ़ाइलों में बताया गया)
  • कनेक्टर की संख्या (आपकी .gql फ़ाइलों में बताई गई).

एसक्यूएल स्कीमा, आपके डेटा का सोर्स ऑफ़ ट्रूथ होता है. Data Connectस्कीमा से यह तय होता है कि आपके कनेक्टर उस डेटा को कैसे देख सकते हैं. साथ ही, कनेक्टर उन एपीआई के बारे में बताते हैं जिनका इस्तेमाल आपके क्लाइंट उस डेटा को ऐक्सेस करने के लिए कर सकते हैं.

सीएलआई के साथ Data Connect सेवा डिप्लॉय करने पर, एसक्यूएल स्कीमा को माइग्रेट किया जाएगा. इसके बाद, Data Connect स्कीमा को अपडेट किया जाएगा. इसके बाद, अपने हर कनेक्टर को अपडेट किया जाएगा.

डिप्लॉयमेंट से जुड़े अहम कॉन्सेप्ट

डिप्लॉयमेंट को पूरी तरह से समझने के लिए, स्कीमा और कनेक्टर के बारे में ज़रूरी कॉन्सेप्ट को ध्यान में रखना ज़रूरी है.

स्कीमा डिप्लॉयमेंट

Data Connect स्कीमा को डिप्लॉय करने से, आपके Cloud SQL डेटाबेस के SQL स्कीमा पर असर पड़ता है. Data Connect, डिप्लॉयमेंट के दौरान स्कीमा को माइग्रेट करने में आपकी मदद करता है. भले ही, आप किसी नए डेटाबेस के साथ काम कर रहे हों या किसी मौजूदा डेटाबेस को बिना किसी नुकसान के अडैप्ट करना हो.

Data Connect स्कीमा माइग्रेशन में, स्कीमा की पुष्टि करने के दो अलग-अलग मोड होते हैं: स्ट्रिक्ट और कंपैटिटबल.

  • सख्त मोड की पुष्टि के लिए यह ज़रूरी है कि ऐप्लिकेशन स्कीमा को अपडेट करने से पहले, डेटाबेस स्कीमा ऐप्लिकेशन स्कीमा से पूरी तरह मेल खाता हो. आपके Data Connect स्कीमा में इस्तेमाल नहीं की गई टेबल या कॉलम, डेटाबेस से मिटा दिए जाएंगे.

  • साथ काम करने वाले मोड की पुष्टि करने के लिए ज़रूरी है कि डेटाबेस स्कीमा, ऐप्लिकेशन स्कीमा के साथ काम करता हो. इसके बाद ही, ऐप्लिकेशन स्कीमा को अपडेट किया जा सकता है. स्कीमा, टेबल या कॉलम को हटाने वाले अन्य बदलाव करना ज़रूरी नहीं है.

    काम करने का मतलब है कि स्कीमा माइग्रेशन का असर सिर्फ़ आपके ऐप्लिकेशन स्कीमा में रेफ़र की गई टेबल और कॉलम पर पड़ता है. आपके डेटाबेस में मौजूद ऐसे एलिमेंट जिनका इस्तेमाल आपके ऐप्लिकेशन स्कीमा में नहीं किया जाता है उन्हें बिना बदलाव के छोड़ दिया जाता है. इसलिए, डिप्लॉयमेंट के बाद, हो सकता है कि आपके डेटाबेस का इस्तेमाल न हुआ हो:

    • स्कीमा
    • टेबल
    • कॉलम

कनेक्टर डिप्लॉयमेंट

Data Connect क्वेरी और म्यूटेशन, क्लाइंट कोड से सबमिट नहीं किए जाते और सर्वर पर लागू नहीं किए जाते. इसके बजाय, डिप्लॉय किए जाने पर Data Connect से जुड़ी ये कार्रवाइयां, सर्वर पर सेव की जाती हैं, जैसे कि Cloud Functions. इसका मतलब है कि डिप्लॉयमेंट से, मौजूदा उपयोगकर्ताओं को समस्याएं आ सकती हैं.

डिप्लॉयमेंट वर्कफ़्लो फ़ॉलो करें

Data Connect प्रोजेक्ट पर, लोकल प्रोजेक्ट डायरेक्ट्री और Firebase कंसोल, दोनों में काम किया जा सकता है.

डिप्लॉयमेंट के लिए सुझाए गए फ़्लो में ये शामिल हैं:

  1. फ़िलहाल, डिप्लॉय किए गए स्कीमा और कनेक्टर को firebase dataconnect:services:list के साथ लिस्ट करना.
  2. स्कीमा के अपडेट मैनेज करना.
    1. firebase dataconnect:sql:diff के साथ अपने Cloud SQL डेटाबेस और स्थानीय डेटा कनेक्ट स्कीमा के बीच SQL स्कीमा अंतरों की जांच करें.
    2. अगर ज़रूरी हो, तो dataconnect:sql:migrate की मदद से एसक्यूएल स्कीमा माइग्रेशन करें.
  3. 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, आपके Data Connect प्रोजेक्ट में अपनाए जाने वाले कुछ तरीकों का सुझाव देता है.

नुकसान पहुंचा सकने वाले बदलावों को कम से कम करें

  • Firebase का सुझाव है कि आप अपने Data Connect स्कीमा और कनेक्टर फ़ाइलों को सोर्स कंट्रोल में रखें.
  • जब हो सके, बदलावों को तोड़ने से बचें. ब्रेकिंग बदलावों के कुछ सामान्य उदाहरणों में ये शामिल हैं:
    • अपने स्कीमा से किसी फ़ील्ड को हटाना
    • आपके स्कीमा में ऐसा फ़ील्ड बनाना जिसे शून्य या न किया जा सके (जैसे, Int -> Int!)
    • अपने स्कीमा में किसी फ़ील्ड का नाम बदलना.
  • अगर आपको अपने स्कीमा से किसी फ़ील्ड को हटाना है, तो असर को कम करने के लिए, इसे कुछ डिप्लॉयमेंट में बांटें:
    • सबसे पहले, अपने कनेक्टर में फ़ील्ड के सभी रेफ़रंस हटाएं और बदलाव को डिप्लॉय करें.
    • इसके बाद, नए जनरेट किए गए SDK टूल का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन अपडेट करें.
    • आखिर में, अपनी स्कीमा .gql फ़ाइल में मौजूद फ़ील्ड हटाएं, अपने एसक्यूएल स्कीमा को माइग्रेट करें, और एक बार और डिप्लॉय करें.

नए डेटाबेस के साथ काम करते समय स्ट्रिक्ट मोड का इस्तेमाल करें

अगर किसी नए डेटाबेस के साथ Data Connect का इस्तेमाल किया जा रहा है और ऐप्लिकेशन स्कीमा को लगातार डेवलप किया जा रहा है, तो dataconnect.yaml में schemaValidation: "STRICT" की जानकारी दी जा सकती है. इससे यह पक्का किया जा सकता है कि आपका डेटाबेस स्कीमा, ऐप्लिकेशन स्कीमा के हिसाब से हो.

इससे यह पक्का होगा कि वैकल्पिक बदलाव भी लागू कर दिए गए हैं.

अगर आपके डेटाबेस में प्रोडक्शन डेटा है, तो कम्पैटबिलिटी मोड का इस्तेमाल करें

अगर आपको किसी ऐसे डेटाबेस में बदलाव करना है जिसमें प्रोडक्शन डेटा शामिल है, तो हमारा सुझाव है कि आप अपने स्कीमा माइग्रेशन को 'काम करने वाले मोड' में लागू करें. इससे यह पक्का हो सकेगा कि मौजूदा डेटा शामिल न हो. dataconnect.yaml में schemaValidation: "COMPATIBLE" का इस्तेमाल किया जा सकता है

कंपैटबिलिटी मोड में, आपके डेटाबेस पर सिर्फ़ स्कीमा माइग्रेशन के ज़रूरी बदलाव लागू किए जाते हैं.

  • DROP SCHEMA, DROP TABLE, और DROP COLUMN को वैकल्पिक स्टेटमेंट माना जाता है. ये आपके प्लान के लिए जनरेट नहीं होंगे. भले ही, आपके डेटाबेस स्कीमा में ऐसे स्कीमा, टेबल या कॉलम हों जो आपके ऐप्लिकेशन स्कीमा में तय नहीं किए गए हैं.
  • अगर आपकी डेटाबेस टेबल में कोई ऐसा कॉलम नहीं है जो आपके ऐप्लिकेशन स्कीमा में शामिल नहीं है, तो NOT NULL कंस्ट्रेंट को हटा दिया जाएगा, ताकि तय किए गए कनेक्टर के साथ टेबल में डेटा अब भी जोड़ा जा सके.

आगे क्या करना है?