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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह इस बात की भी पुष्टि करता है कि Data Connect स्कीमा को अपडेट करने से पहले, SQL स्कीमा पहले से ही माइग्रेट हो चुका है. अगर ऐसा नहीं है, तो यह आपको अपने-आप किसी भी स्कीमा माइग्रेट करने के ज़रूरी चरण.

--force फ़्लैग डिप्लॉयमेंट

firebase deploy --only dataconnect --force

अगर कनेक्टर या एसक्यूएल स्कीमा की पुष्टि करने में कोई समस्या नहीं है, तो उन्हें अनदेखा करने के लिए, --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 टूल का इस्तेमाल किया जा सकता है.

एसक्यूएल स्कीमा में हुए बदलावों के बीच अंतर

इन बदलावों की पुष्टि की जा सकती है:

firebase dataconnect:sql:diff

सेवाओं की कॉमा लगाकर अलग की गई सूची दी जा सकती है.

कमांड किसी सेवा के लिए लोकल स्कीमा की तुलना, संबंधित Cloud 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" की जानकारी दी जा सकती है. इससे यह पक्का किया जा सकता है कि आपका डेटाबेस स्कीमा, ऐप्लिकेशन स्कीमा के हिसाब से हो.

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

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

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

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

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

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