פריסה וניהול של סכימות ומחברים של Data Connect

שירות Firebase Data Connect מורכב משלושה רכיבים עיקריים:

  • מסד נתונים ב-PostgreSQL עם סכימה משלו של SQL
  • סכימה של אפליקציה ב-Data Connect (הצהרה עליה בקובצי .gql)
  • מספר מחברים (שמוצגים בקבצים .gql).

סכימת ה-SQL היא המקור האמיתי לנתונים שלכם, הסכימה Data Connect היא האופן שבו המחברים יכולים לראות את הנתונים האלה, והמחברים מצהירים על ממשקי ה-API שבהם הלקוחות שלכם יכולים להשתמש כדי לגשת לנתונים האלה.

כשפורסים את שירות Data Connect באמצעות CLI, צריך להעביר את הסכימה של SQL, לאחר מכן לעדכן את הסכימה של Data Connect ואז לעדכן כל אחד מהמחברים.

מושגים חשובים בנושא פריסה

כדי להבין את הפריסה במלואה, חשוב להכיר מושגים מרכזיים לגבי סכימות ומחברים.

פריסות של סכימות

הפריסה של סכימה מסוג Data Connect משפיעה על הסכימה של SQL במסד הנתונים ב-Cloud SQL. Data Connect עוזר להעביר את הסכימות במהלך הפריסה, בין שאתם עובדים עם מסד נתונים חדש ובין שאתם צריכים להתאים מסד נתונים קיים ללא השמדת נתונים.

להעברות של סכימות Data Connect יש שני מצבי אימות שונים של סכימות: strict ו-compatible.

  • באימות במצב קפדני, סכימת מסד הנתונים צריכה להתאים בדיוק לסכימת האפליקציה לפני שאפשר לעדכן את סכימת האפליקציה. כל הטבלאות או העמודות שלא נמצאות בשימוש בסכימה Data Connect יימחקו מהמסד הנתונים.

  • כדי לבצע אימות במצב תואם, הסכימה של מסד הנתונים צריכה להיות תואמת לסכימה של האפליקציה לפני שאפשר לעדכן את הסכימה של האפליקציה. שינויים נוספים שמובילים להסרה של סכימות, טבלאות או עמודות הם אופציונליים.

    התאימות מאפשרת להעביר את הסכימה רק לטבלאות ולעמודות שמופיעות בהפניות בסכמת האפליקציה. רכיבים במסד הנתונים שלא משמשים את הסכימה של האפליקציה לא משתנים. לכן, אחרי הפריסה, מסד הנתונים עשוי להכיל:

    • סכימות
    • טבלאות
    • עמודות

פריסות של מחברים

שאילתות ומוטציות של Data Connect לא נשלחות על ידי קוד הלקוח ומבוצעות בשרת. במקום זאת, כשמבצעים פריסה, פעולות ה-Data Connect נשמרות בשרת, כמו Cloud Functions. המשמעות היא שהפריסה עלולה לגרום לתקלה במשתמשים קיימים.

פועלים לפי תהליך העבודה לפריסה

אפשר לעבוד על פרויקט Data Connect גם בספריית פרויקטים מקומית וגם במסוף Firebase.

תהליך הפריסה המומלץ כולל:

  1. הצגת רשימה של המחברים והסכימות שנפרסו כרגע באמצעות firebase dataconnect:services:list.
  2. ניהול עדכוני סכימות.
    1. בעזרת firebase dataconnect:sql:diff אפשר לבדוק את ההבדלים בין הסכימה של SQL במסד הנתונים ב-Cloud SQL לבין הסכימה המקומית של Data Connect.
    2. אם יש צורך, מבצעים העברה של סכימה של SQL באמצעות dataconnect:sql:migrate.
  3. ביצוע פריסות של סכימה ומחברים על ידי הפעלת firebase deploy, רק עבור הסכימה, רק עבור המחברים או שילובים של משאבים.

פריסה וניהול של משאבי Data Connect

מומלץ לאמת את משאבי הייצור לפני שמבצעים פריסות.

firebase dataconnect:services:list

כשעובדים בספריית פרויקט מקומית, בדרך כלל משתמשים בפקודה firebase deploy כדי לפרוס את הסכימה ואת המחברים בסביבת הייצור, עם משוב אינטראקטיבי.

הדגל --only dataconnect מאפשר להפריד בין פריסות Data Connect למוצרים אחרים בפרויקט באמצעות כל אחת מהפקודות deploy.

פריסה רגילה

firebase deploy --only dataconnect

בפריסה הרגילה הזו, ה-CLI Firebase מנסה לפרוס את הסכימה והמחברים.

הוא מאמת שהסכימה החדשה לא גורמת לשבירה של מחברים קיימים. כשמבצעים שינויים שגורמים לשיבושים, חשוב לפעול לפי השיטות המומלצות.

הוא גם מאמת שהסכימה של SQL כבר הועברה לפני עדכון הסכימה Data Connect. אם לא, יוצגו לכם באופן אוטומטי השלבים הנדרשים להעברת הסכימות.

פריסת הדגל --force

firebase deploy --only dataconnect --force

אם לא אכפת לכם מהאימותים של המחבר או של הסכימה של SQL, תוכלו להריץ מחדש את הפקודה עם --force כדי להתעלם מהם.

פריסת --force עדיין בודקת אם הסכימה של SQL תואמת להסכימה של Data Connect, מזהירה על חוסר תאימות ומציגה הנחיות.

פריסה של המשאבים שנבחרו

כדי לפרוס עם בקרה פרטנית יותר, משתמשים בדגל --only עם הארגומנט serviceId. כדי לפרוס רק שינויים בסכימה של שירות מסוים:

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]

בסביבות אינטראקטיביות מוצגות הצהרות העברה של SQL והנחיות לביצוע פעולות.

מעבר במצב מחמיר או תואם

בפרויקט חדש לגמרי, מצב אימות הסכימה שמוגדר כברירת מחדל חל. הפקודה migrate מחילה את כל השינויים בסכמה של מסד הנתונים שנדרשים לסכמה של האפליקציה, ולאחר מכן מבקשת ממכם לאשר פעולות אופציונליות להסרת סכימות, טבלאות או עמודות כדי לאלץ את הסכמה של מסד הנתונים להתאים בדיוק לסכמה של האפליקציה.

אפשר לשנות את ההתנהגות הזו על ידי שינוי הקובץ dataconnect.yaml. מבטלים את התגובה למפתח schemaValidation ומצהירים על COMPATIBLE כדי להחיל רק את השינויים הנדרשים בהעברות.

schemaValidation: "COMPATIBLE"

או להגדיר את ההתנהגות ל-STRICT כדי להחיל את כל השינויים בסכימה והסכימה של מסד הנתונים תאלץ להתאים את הסכימה של האפליקציה.

schemaValidation: "STRICT"

מידע נוסף זמין בData Connectחומר העזרה של CLI.

שיטות מומלצות לניהול סכימות ומחברים

ב-Firebase יש כמה שיטות מומלצות לשימוש בפרויקטים שלכם ב-Data Connect.

צמצום השינויים שעלולים לגרום לכשל

  • מומלץ לשמור את הסכימה ואת קובצי המחבר של Data Connect במערכת בקרת הגרסאות של Firebase.
  • כשאפשר, נמנעים משינויים שעלולים לגרום לכשל. דוגמאות נפוצות לשינויים שגורמים לשגיאות:
    • הסרת שדה מהסכימה
    • הגדרת שדה אפסי בסכימה שאינו null (למשל Int -> Int!)
    • שינוי השם של שדה בסכימה.
  • אם אתם צריכים להסיר שדה מהסכימה, כדאי לפצל אותו לכמה פריסות כדי למזער את ההשפעה:
    • קודם כול, מסירים את כל ההפניות לשדה במחברים ופורסים את השינוי.
    • לאחר מכן, עליכם לעדכן את האפליקציות כדי להשתמש ב-SDKs החדשים שנוצרו.
    • לבסוף, מסירים את השדה בקובץ .gql של הסכימה, מעבירים את הסכימה של SQL ופורסים אותה שוב.

שימוש במצב קפדני כשעובדים עם מסדי נתונים חדשים

אם אתם משתמשים ב-Data Connect עם מסד נתונים חדש ומפתחים את הסכימה של האפליקציה באופן פעיל, ואתם רוצים לוודא שהסכימה של מסד הנתונים תואמת בדיוק לסכימת האפליקציה, אפשר לציין את הערך schemaValidation: "STRICT" ב-dataconnect.yaml.

כך תוכלו לוודא שהשינויים האופציונליים יחולו גם הם.

שימוש במצב תואם כשיש נתוני ייצור במסד הנתונים

אם אתם מבצעים שינויים במסד נתונים שמכיל נתוני ייצור, מומלץ לבצע את ההעברות של הסכימה במצב תואם, כדי להבטיח שהנתונים הקיימים לא יוסרו. אפשר לציין את schemaValidation: "COMPATIBLE" ב-dataconnect.yaml

במצב תואם, רק השינויים הנדרשים בהעברת הסכימה חלים על מסד הנתונים.

  • DROP SCHEMA,‏ DROP TABLE ו-DROP COLUMN נחשבים לביטויים אופציונליים ולא יופקו עבור התוכנית, גם אם הסכימה של מסד הנתונים מכילה סכימות, טבלאות או עמודות שלא מוגדרות בסכימה של האפליקציה.
  • אם טבלת מסד הנתונים מכילה עמודה שהיא לא אפסית שלא כלולה בסכימת האפליקציה, האילוץ NOT NULL יוסר כדי שהנתונים עדיין יתווספו לטבלה עם המחברים שהגדרתם.

מה השלב הבא?