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

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

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

एसक्यूएल स्कीमा, आपके डेटा का सोर्स ऑफ़ ट्रूथ होता है. 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 कंसोल, दोनों में काम किया जा सकता है.

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

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

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

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

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

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

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

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

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

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