פריסה וניהול של סכימות ומחברים של 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 כדי לפרוס את הסכימה ואת המחברים בסביבת הייצור, עם משוב אינטראקטיבי.

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

פריסה רגילה

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.
  • כשאפשר, נמנעים משינויים שעלולים לגרום לכשל. דוגמאות נפוצות לשינויים שגורמים לשגיאות:
    • הסרת שדה מהסכימה
    • שינוי שדה nullable בסכימה לשדה שאינו nullable (כלומר Int -> Int!)
    • שינוי שם של שדה בסכימה.
  • אם אתם צריכים להסיר שדה מהסכימה, כדאי לפצל אותו לכמה פריסות כדי למזער את ההשפעה:
    • קודם כול, מסירים את כל ההפניות לשדה במחברים ופורסים את השינוי.
    • בשלב הבא, מעדכנים את האפליקציות כך שישתמשו בערכות SDK חדשות שנוצרו.
    • לבסוף, מסירים את השדה בקובץ .gql של הסכימה, מעבירים את הסכימה של SQL ופורסים אותה שוב.

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

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

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

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

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

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

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

מה השלב הבא?