כלי סכימה — טבלאות ושדות

שלושה כלים מכסים את שכבת הסכימה: אחד קורא (Get-Schema) ושניים כותבים (Create-Table, Add-Field-to-Table).

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

הכלל הראשון של הפלטפורמה

לפני כל פעולה על טבלה שאתם לא מכירים — Get-Schema. הסכימה שונה בין לקוח ללקוח: שדות מותאמים, שדות שהוסרו, טבלאות lookup עם מזהים שנוצרו במערכת הספציפית הזו. ניחוש שם שדה לא מחזיר שגיאה — הוא מחזיר 200 ושדה ריק. ראו סכימות — לקרוא לפני שכותבים.

Get-Schema

מחזיר את מבנה הטבלאות והשדות. בלי className — כל הטבלאות במערכת; עם className — טבלה אחת.

הפרמטר	טיפוס	חובה	המשמעות
className	String		שם המחלקה. בלי הפרמטר מוחזרת הסכימה של כל הטבלאות
tablesNameOnly	Boolean		true = רק שמות הטבלאות, בלי השדות

JSON

// טבלה אחת — זו הקריאה שתעשו בפועל
{ "className": "Accounts" }

// רק שמות הטבלאות — מיפוי מהיר של מערכת חדשה
{ "tablesNameOnly": true }

tablesNameOnly — הפרמטר שקל לפספס

תיאורים ישנים של Get-Schema מונים פרמטר אחד בלבד (className). הסכימה החיה חושפת גם tablesNameOnly — והיא הקובעת. זה הפרמטר שהופך את “תראה לי מה יש כאן” מתשובה של מגה‑בייטים לרשימה קריאה: בסביבת ייחוס יש כ‑196 טבלאות ו‑2,592 שדות, וסכימה מלאה של מערכת כזו מציפה חלון הקשר של מודל שפה.

מה חוזר

התשובה היא אובייקט שמפתחו שם המחלקה: { "Accounts": { "Name": "String", "StatusId": { "type": "Pointer", "targetClass": "AccountStatuses", "dictionary": "סטטוס" }, … } }. שדה פשוט מיוצג במחרוזת הטיפוס; שדה Pointer — באובייקט עם type ו‑targetClass. שדה שיש לו תווית נושא גם dictionary — התווית בעברית שנשמרה עבורו בטבלת _Dictionary (שם הטבלה ב‑tblName, השדה ב‑field, התווית ב‑value), וזו התווית שהמשתמש רואה בדפים ובבורר העמודות.

dictionary מוחזר עם HTML entities

תווים כמו ( ) " & נשמרים ב‑_Dictionary מקודדים — תווית שנכתבה דירוג (1-5) חוזרת כ‑דירוג (1-5). בדף עצמו היא מוצגת נכון; סוכן שמשווה או מציג תוויות מתוך הסכימה צריך לפענח entities קודם.

השדות שכל רשומה מקבלת אוטומטית, בכל טבלה: objectId (10 תווים), createdAt, updatedAt, createdBy (Pointer ל‑_User), updatedBy (Pointer ל‑_User) ו‑ACL.

הטריגרים אינם חלק מתשובת Get-Schema — גם לטבלה בודדת חוזרים השדות בלבד. את הגדרות האוטומציה של טבלה קוראים ב‑Get-Triggers.

הטיפוסים

ה‑enum של הסכימה החיה — בשני כלי הכתיבה — מכיל עשרה טיפוסים בדיוק:

הטיפוס	איך זה נראה בטופס	מתי משתמשים
String	<input type="text">	שמות, טקסט חופשי
Number	<input type="number">	סכומים, דירוגים. סכום/ממוצע/מינימום/מקסימום בטבלאות ובדוחות עובדים רק על Number
Boolean	תיבת סימון	דגלים (Active, IsVIP)
Date	בורר תאריך	דד‑ליינים, אירועים
Array	ווידג’ט רב‑ערכי	תגיות, בחירה מרובה — ראו מוסכמת השם למטה
Object	(אין ווידג’ט סטנדרטי)	בלוקים מובנים. הימנעו בשדות שמשתמש נוגע בהם
Pointer	<select class="select-pointer">	כל רשימה נפתחת וכל קשר בין טבלאות
File	ווידג’ט העלאה	קובץ ציבורי
PrivateFile	ווידג’ט העלאה	קובץ שדורש הרשאה להורדה
GeoPoint	—	מיקום. כמעט לא בשימוש במודולי ה‑CRM

טיפוסים שאפשר לקרוא ואי אפשר ליצור

בקריאת סכימה תיתקלו גם ב‑Relation, HTML/XML, ACL ו‑AutoIncrement — והם אינם ב‑enum של כלי הכתיבה. AutoIncrement (מספר רץ, כמו Cases.Number) קיים בפלטפורמה ומוגדר בממשק הניהול בלבד. בטבלת תצוגה או בדוח מציינים את הטיפוס כ‑AutoIncrement, אבל השדה יתנהג ככזה רק אם ב‑DB הוא באמת מספר רץ. מאחוריו יושבת טבלת _AutoIncrementValues — אל תערכו אותה ידנית, זו הדרך לקבל מספרים כפולים.

מוסכמות שמות

• שם שדה: /^[A-Za-z][A-Za-z0-9_]*$/, CamelCase — PhoneNumber, ContractEndDate.
• שדה Pointer מסתיים ב‑Id — StatusId, OwnerId, AccountId. זו לא דרישה של השרת אלא מוסכמת המוצר, וכל התיעוד וכל הכלים מניחים אותה.
• שם טבלה: אותו regex, PascalCase, ברבים — Projects, SaleRows, ProjectStatuses.
• שדה Array של Pointers: השם הוא זה שקובע את סוג הפריטים. המוסכמה שקוד הריצה מזהה היא array_<purpose>_Pointer_<TargetTable> — למשל array_languages_Pointer_Languages — והיא מרנדרת <select multiple> אמיתי בלי שורת JS אחת. תיאור הכלי מדגים גם את הצורה SalesId_Pointer_Sales. שדה Array בלי מוסכמת השם מתנהג כמערך אטום, בלי ווידג’ט.

Create-Table

יוצר טבלה חדשה. שדה Name מסוג String נוסף אוטומטית — אל תגדירו אותו שוב.

הפרמטר	טיפוס	חובה	המשמעות
name	String	✔	שם הטבלה. /^[A-Za-z][A-Za-z0-9_]*$/
fields	Array<Object>		מערך שדות. בלי הפרמטר — הטבלה נוצרת עם Name בלבד

אובייקט השדה (זהה בשני כלי הכתיבה):

המפתח	טיפוס	חובה	המשמעות
name	String	✔	שם השדה, באותו regex
type	Enum	✔	אחד מעשרת הטיפוסים למעלה
label	String		התווית בעברית — “to put in the html”. זה מה שהמשתמש רואה
targetClass	String	ל‑Pointer	המחלקה שאליה השדה מצביע

JSON

{
  "name": "Suppliers",
  "fields": [
    { "name": "SupplierCode", "type": "String",  "label": "קוד ספק" },
    { "name": "Rating",       "type": "Number",  "label": "דירוג (1-5)" },
    { "name": "Active",       "type": "Boolean", "label": "ספק פעיל" },
    { "name": "JoinDate",     "type": "Date",    "label": "תאריך הצטרפות" },
    { "name": "StatusId",     "type": "Pointer", "targetClass": "SupplierStatuses", "label": "סטטוס" },
    { "name": "AccountId",    "type": "Pointer", "targetClass": "Accounts",         "label": "לקוח" },
    { "name": "OwnerId",      "type": "Pointer", "targetClass": "_User",            "label": "אחראי" }
  ]
}

שימו לב: targetClass אינו נבדק מול הסכימה. Pointer ל‑SupplierStatuses ייווצר גם אם הטבלה הזו עדיין לא קיימת — הכלי יחזיר success, והרשימה הנפתחת תישאר ריקה עד שתיצרו אותה. לכן סדר העבודה מתחיל בטבלאות ה‑lookup.

למה דרך הכלי ולא כתיבת סכימה גולמית

אפשר ליצור טבלה גם ב‑POST /parse/schemas/<Class> עם Master Key, וזו נראית אותה פעולה. היא לא.

מה שקורה	דרך הכלי	דרך REST גולמי
הטבלה והשדות נוצרים	✔	✔
התווית בעברית נכתבת ל‑_Dictionary	✔ (מהפרמטר label)	✖ — השדה יופיע בשמו האנגלי בכל דף ובכל בורר עמודות
הרשאות טבלה (CLP) מוגדרות	✔	✖ — הטבלה נולדת עם CLP ריק
ACL לרשומות שנוצרות	לפי המסלול שיצר את הרשומה	✖ — רשומות שנוצרו ב‑REST נולדות בלי ACL, ומשתמשים מחוברים עלולים לא לראות אותן

שכבת ה‑REST מדלגת על שתי השכבות הראשונות מפני שהן שכבות מוצר, לא שכבות Parse. התוצאה של יצירה ב‑REST היא טבלה שנראית תקינה ב‑Get-Schema ומייצרת שתי תקלות אצל הלקוח: שמות שדה באנגלית בממשק עברי, ו“אין לך הרשאות” בכל דף שמבוסס עליה.

אם בכל זאת יצרתם טבלה ב‑REST

שני צעדי תיקון, מיד: (א) Set-Table-Permissions עם CLP מבוסס תפקידים, ו**(ב)** תוויות עברית — או בעת הצבת השדה על הדף (label ב‑Edit-Page), או בממשק הניהול. פרטי נקודת הקצה: Schemas API.

"missing user" — שגיאה ישנה שאינה חוזרת

בגרסאות שרת ישנות Create-Table החזיר missing user בחלק מהסביבות. בגרסאות עדכניות, מחיבור עם Master Key, קריאות ל‑Create-Table (עם fields ובלעדיו) מצליחות ויוצרות טבלה עם תוויות ו‑CLP. אם בכל זאת נתקלתם בהודעה — עברו ל‑REST וזכרו את שני צעדי התיקון למעלה.

שם טבלה לא חוקי מחזיר Error: [object Object]

שם שאינו תואם את ה‑regex (למשל Bad-Name, 1Bad, Bad Name) נדחה — אבל ההודעה היא Error: [object Object] בלי הסבר. כשזו התשובה, בדקו קודם את שם הטבלה. Add-Field-to-Table מחזיר במקרה המקביל הודעה ברורה: invalid field name: Bad-Name.

Add-Field-to-Table

מוסיף שדות לטבלה קיימת — ויודע ליצור טבלת lookup חדשה ולזרוע בה ערכים באותה קריאה.

הפרמטר	טיפוס	חובה	המשמעות
table	String	✔	הטבלה שמרחיבים
fields	Array<Object>	✔	אותו אובייקט שדה כמו ב‑Create-Table
newTableName	String		שם טבלת lookup חדשה שתיווצר עבור שדה ה‑Pointer
newTableValues	Array<String>		ערכי Name לזריעה בטבלה החדשה

הוספה פשוטה:

JSON

{
  "table": "Accounts",
  "fields": [
    { "name": "Website",     "type": "String", "label": "אתר אינטרנט" },
    { "name": "FoundedYear", "type": "Number", "label": "שנת הקמה" }
  ]
}

דפוס הרשימה הנפתחת בקריאה אחת

JSON

// יוצר את TaskCategories עם 5 רשומות, ומוסיף Tasks.CategoryId שמצביע אליה
{
  "table": "Tasks",
  "fields": [
    { "name": "CategoryId", "type": "Pointer", "targetClass": "TaskCategories", "label": "קטגוריה" }
  ],
  "newTableName": "TaskCategories",
  "newTableValues": ["פיתוח", "תמיכה", "מכירות", "שיווק", "אחר"]
}

שימו לב ש‑targetClass בתוך fields ו‑newTableName חייבים להיות אותו שם. הכלי מבצע כאן שלוש פעולות: יוצר טבלה, זורע בה רשומות, ומחבר אליה שדה Pointer.

newTableValues זורע רק את Name

צבע (Color), סדר (Order) או דגל פעיל (Active) על טבלת ה‑lookup החדשה דורשים מעבר נוסף עם Create-Many או Update-Data. התשובה מדווחת כמה רשומות נזרעו: "newTableValuesCreated": 5.

מגבלה ידועה — טבלת ה‑lookup החדשה נולדת בלי הרשאות בכלל

בניגוד ל‑Create-Table, שמגדיר CLP מבוסס תפקידים (find/get למשתמשים מחוברים, create/update/delete ל‑role:Admin), הטבלה שנוצרת דרך newTableName מקבלת CLP ריק — { "find": {}, "get": {}, … }. ב‑Parse פירושו שאף משתמש מחובר, כולל Admin, לא יכול לקרוא אותה: כל רשימה נפתחת, גרף או דוח שנשענים עליה ייכשלו ב‑Permission denied for action find (HTTP 400), ורק חיבור Master רואה את הערכים. מיד אחרי הקריאה: Set-Table-Permissions על הטבלה החדשה (או classLevelPermissions ב‑REST).

targetClass — מה זה באמת אומר

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

כל dropdown ב‑MyBusiness הוא טבלה נפרדת ועוד שדה Pointer — לעולם לא רשימת ערכים סטטית.

1. טבלת הערכים — רשומה אחת לכל אפשרות; השדה Name הוא הטקסט המוצג. שדות נוספים מקובלים: Color (מחרוזת hex — משמש לתגיות סטטוס ולעיצוב מותנה), Order (Number, למיון) ו‑Active (Boolean).
2. שדה ה‑Pointer על הטבלה הראשית — SaleStatusId שמצביע ל‑SaleStatuses.

ההשלכות המעשיות:

• הוספה, שינוי שם או סידור מחדש של אפשרויות = עריכת רשומות בטבלת הערכים. רשומות קיימות ממשיכות להצביע לאותו objectId, ולכן שינוי שם של אפשרות לא שובר היסטוריה.
• ערך Pointer בפעולת נתונים הוא תמיד האובייקט המלא: {"__type":"Pointer","className":"SaleStatuses","objectId":"zrP1MSVBoq"}. ראו סוגי נתונים.
• ב‑targetClass של משתמש הערך הוא _User — ושדות ה‑_User הם באותיות קטנות: name, email, phone. זו טעות חוזרת בכל מסלול Pointer בטבלאות תצוגה ובדוחות.
• רשימות נפתחות מדורגות (סוג ← תת‑סוג) אינן נבנות בחוקי טופס אלא במנגנון האב/בן המובנה — subclassDepend ב‑Edit-Page.

מה אי אפשר לעשות

הפעולה	MCP	ממשק הניהול	REST עם Master Key
הוספת שדה	✔ Add-Field-to-Table	✔	✔ PUT /parse/schemas/<Class>
שינוי שם שדה	✖	✖	✖ — מגבלת Parse. הפתרון: שדה חדש + העברת נתונים
שינוי טיפוס שדה	✖	✖	✖ — אותה מגבלה
מחיקת שדה	✖	✔	✔ {"fields":{"FieldName":{"__op":"Delete"}}} — מוחק את העמודה ואת הנתונים
מחיקת טבלה	✖	✔	✔ DELETE /parse/schemas/<Class> (רק כשהיא ריקה)
עדכון התווית ב‑_Dictionary	✖ — ה‑label נכתב פעם אחת, ביצירה	✔	—
הסרת שדה מדף (נשאר ב‑DB)	✔ Edit-Page	✔	—

הסרה מדף אינה מחיקה מהסכימה

remove-existing-field ב‑Edit-Page מוריד את השדה מהטופס. הוא נשאר בסכימה, הנתונים נשארים בו, והוא ימשיך להופיע ב‑Get-Schema, בבורר העמודות של טבלאות התצוגה וב‑Get-Optional-Fields. זו התנהגות רצויה — אבל מי שמצפה ש“מחקתי את השדה” יופתע.

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

סדר העבודה לטבלה חדשה

1. Get-Schema על הטבלאות הקשורות — לאמת יעדי Pointer ולמנוע התנגשות שמות.
2. טבלאות lookup קודם (<Entity>Statuses עם Name ו‑Color), אחר כך הטבלה הראשית, ואז טבלאות הבן — כל בן מקבל Pointer חזרה לאב.
3. label בעברית על כל שדה בזמן היצירה — זה הרגע הזול היחיד לעשות את זה.
4. Set-Table-Permissions — CLP מבוסס תפקידים על כל טבלה חדשה.
5. זריעת ערכי ה‑lookup (Create-Many) לפני שבונים דפים.
6. אימות: Get-Schema על הטבלה החדשה מראה את השדות; Get-Table-Permissions (הפרמטר שלו הוא table, לא tableName) מראה מפתחות role:; Count-Data מחזיר את הרשומות שנזרעו.

ומכאן ממשיכים לדפים: Create-Form-Page ← Edit-Page ← Create-Table-View-Page ← חוקי טופס.

המשך

• אתרים ודפים — קריאה · עריכת דפים ואלמנטים
• תפקידים, הרשאות טבלה וחבילות — הצעד שאסור לדלג עליו אחרי יצירת טבלה
• טבלאות תצוגה ודפי רשימה — Get-Optional-Fields ודוקטרינת aggrField
• כלי נתונים — לזרוע ולקרוא את מה שיצרתם
• סכימות ב‑REST · מפת הטבלאות המרכזיות · סוגי נתונים
• אינדקס הכלים המלא