ניהול גרסאות v1 בפידים באצווה

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

{
  "@context": "http://schema.googleapis.com",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "@type": "DataFeed",
  "dataFeedElement": [
    /* All the items that are part of this feed go here */
  ]
}

לכל הישויות שמפורטות בשדה dataFeedElement תהיה חותמת זמן זהה, כפי שמצוין במעטפה.

לדוגמה, הפיד הבא יכול לכלול שתי ישויות:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/somerestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/somerestaurant/menu/1"
      ...
    }
  ]
}

לאחר קבלת ועיבוד ישויות התפריט ורכיבי המסעדות, כל אחת מהן תסווג בנפרד כ-"2018-12-28T06:30:00:123-07:00".

גרסאות עם עדכונים מצטברים

כששולחים ישות באמצעות עדכוני מלאי, הגרסה מוגדרת באמצעות השדה update_time (במקרה של קריאה להוספה או עדכון) או באמצעות השדה delete_time (במקרה של קריאת מחיקה). השדות האלה הם אופציונליים, ולכן חותמת הזמן המוגדרת כברירת מחדל היא התאריך שבו Google קיבלה את השיחה.

דוגמה 1: update_time מוגדר באופן מפורש

נניח שהשיחה המצטברת הבאה התקבלה ב-2018-12-28T06:30:10:123-07:00 לגבי מסעדה חדשה לגמרי. בהמשך מוצגת בקשת ה-HTTP POST לישות עם המזהה http://www.provider.com/somerestaurant", בהנחה שפיד הנתונים משתמש בסכימת המלאי v1:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

למטה, הגוף של המטען הייעודי (payload) של JSON מכיל את השדה update_time. הישות עם המזהה "http://www.provider.com/somerestaurant" תמיר את הישות הזו ל-6:30:00 ולא במועד קבלתה (עשר שניות מאוחר יותר, ב-6:30:10):

{
// This envelope is to be used for incremental.
  "entity": {
    // Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

דוגמה 2: update_time מוגדר באופן מרומז

נניח שהשיחה המצטברת הבאה התקבלה ב-2018-12-28T06:30:10:123-07:00 לגבי מסעדה חדשה לגמרי. זוהי בקשת ה-HTTP POST לישות עם המזהה http://www.provider.com/somerestaurant", בהנחה שהפיד משתמש בסכימת המלאי v1:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

למטה, גוף המטען הייעודי (payload) של JSON לא מכיל את השדה update_time. לכן, הישות עם המזהה "http://www.provider.com/somerestaurant" יוצרת את הגרסה של הישות הזו כ-6:30:10:

{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  }
}

ניהול גרסאות בין אצווה לבין גרסאות מצטברות

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

שיטות מומלצות

• מגדירים את השדות update_time ו-dateModified בו-זמנית ובאצווה, בהתאם למועד שבו הישות שונתה במערכות שלכם.
• אם פיד אצווה (קובץ) מכיל יותר מישות אחת ברמה העליונה (לדוגמה, מתאימים את המסעדות עם שירותים ותפריטים), ומעדכנים את חותמת הזמן בכל פעם שהנתונים של ישות מתעדכנים.
• בשיחות מצטברות, מומלץ מאוד להגדיר באופן מפורש את השדה update_time.
• אחרי שמבצעים קריאה מצטברת, חשוב לעדכן גם את חותמת הזמן של הפיד המתאים (dateModified) לפני ש-Google תאחזר אותה שוב.

דוגמה

Google מאחזרת את הקובץ הבא בשעה 11:00 ב-28 באוקטובר 2018 עבור מסעדה חדשה לגמרי:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

הישויות האלה מעובדות בהצלחה והגרסה שלהן משתנה: "2018-12-28T06:30:00-07:00". בגלל שהעיבוד של פידים באצווה לוקח זמן, הם בדרך כלל מוצגים יומיים אחרי כן.

אבל בשעה 13:00, במערכת של השותף יש עדכון למספר הטלפון של המסעדה, וכתוצאה מכך השיחה המצטברת הבאה מתקבלת ב-13:05 (5 שניות אחרי כן):

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  },
  "update_time":"2018-12-28T13:00:00-07:00"
}

השדה update_time צוין במפורש, והוא גדול יותר (עדכני יותר) מהגרסה הקודמת (6:30 באותו יום), ולכן ישות המסעדה נקראת עכשיו "2018-12-28T13:00:00-07:00". עם זאת, ישויות התפריט וישויות השירות עדיין מופיעות בגרסה '2018-12-28T06:30:00-07:00'.

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

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T13:00:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

ביום המחרת (29 באוקטובר 2018) בשעה 23:00, הפיד יאוחזר שוב. הגרסה של המסעדה עדיין זהה (13:00 ב-28 בדצמבר), ולכן הישות הזו נמחקת והגרסה הנוכחית נשמרת. עם זאת, הישויות 'תפריט' ו'שירות' מעודכנות בגרסה חדשה.

חותמות זמן של Sitemap

כותרת התגובה last-modified ב-sitemap לא משפיעה על הגרסה של הישות. היא משפיעה על העיתוי של אחזור הפיד על ידי Google.

שיטות מומלצות

• מעדכנים את כותרת התגובה רק כשכל הקבצים מעודכנים ומוכנים לאחזור.
• שימוש מפורש ב-update_time וב-delete_time במצטבר.
• מגדירים את update_time, delete_time ו-dateModified כשהנתונים משתנים בצד שלכם.