كيف تعمل إصدارات Datastore وApp على GAE/J

Question

يمكن للمرء نشر عدة إصدارات من نفس التطبيق على GAE/J، ولكن كيف يتعامل GAE/J مع حقيقة أن الإصدارات المختلفة يمكن أن تستخدم مخططات مختلفة لمخزن البيانات (وربما غير متوافقة)؟

مثال:

لنفترض أنه في الإصدار 1 من تطبيقي لدي POJO مثل (لقد استبعدت العديد من التفاصيل من أجل البساطة):

public class User {

  private String key;

  private String username;

  private Integer phoneNumber;

}

لنفترض الآن أنني أريد استخدام الإصدار 2:

public class User {

  private String key;

  private String username;

  // on this version, replaced 'phoneNumber' by: 
  private String eMail;

}

الآن سؤالان:

1. إذا قمت بنشر كلا الإصدارين من GAE/J، ما هو المخطط الذي سأراه في مخزن البيانات؟

2. ماذا عن البيانات نفسها؟إذا قمت بإضافة مستخدم في الإصدار 2، فهل سأرى بياناته في مخزن البيانات الخاص بالإصدار 1؟

Answer 1

نقلا عن المستندات,

على عكس قواعد البيانات العلائقية ، فإن التطبيق لا يتطلب مخزن بيانات المحرك ذلك جميع الكيانات من نوع معين لديها نفس الخصائص.يمكن للتطبيق تحديد نموذج البيانات الخاص به وفرضه باستخدام المكتبات المضمنة مع SDK ، أو رمزها الخاص.

وقد تمت الإشارة إلى هذا أيضًا باسم "المخطط الناعم" - لكن مخزن البيانات لا يفعل ذلك حقًا يفعل المخططات، ولكن يمكنك محاكاة بعض أنواع المخططات بشكل أو بآخر عبر رمز مستوى التطبيق (الخاص بك، أو في المكتبات).

لذا، إذا قمت (عبر المكتبة أو في التعليمات البرمجية الخاصة بك) بفرض قيد ينص على "يجب أن تكون هذه السمة موجودة"، ولا يمتلك كيان معين هذه السمة فعليًا (لأنه تم إدراجه بناءً على "مخطط بسيط" مختلف) ، على سبيل المثال إصدار مختلف من التطبيق)، فستحصل على أي استثناء تختاره التعليمات البرمجية على مستوى التطبيق أو المكتبة الخاصة بك للإشارة إلى انتهاك هذا القيد الناعم، عند النقطة التي يتم فيها التحقق من القيد.

إذا لم تقم بالتعبير عن مثل هذه القيود، فستكون للسمة المفقودة إما قيمة افتراضية مقدمة من التعليمات البرمجية أو المكتبة الخاصة بك، أو "افتراضي افتراضي"، والذي أعتقد أنه عادة ما يكون null في جافا أو None في بايثون.

لاحظ أن الإصدارات المختلفة من التطبيق قد تستخدم أوقات تشغيل مختلفة (بعضها قد يكون Java والبعض الآخر قد يكون Python) وسوف تكون أوقات التشغيل المختلفة ما زال استخدم نفس مخزن البيانات، لذا فإن التمييز بين Java وPython ليس مهمًا هنا.

في مثالك المحدد (مع عدم تقديم أي افتراضي وعدم وجود تأكيد حول التواجد الإلزامي) أتوقع أن إضافة مستخدم من أي من الإصدارين سيجعله مرئيًا من الآخر، مع رؤية السمات المفقودة على أنها null (ولكن قد تكون هناك قيود لست على علم بها، وفي هذه الحالة يجب أن ينتج استثناء عندما تحاول المكتبة التحقق من صحة هذه القيود وترى أنه تم انتهاكها).

بشكل عام، لن أقلق بشأن إضافة سمات "اختيارية" (تلك التي قد تكون مفقودة/null/None, ، أو يكون لها افتراضي واضح في تلك الحالات، بحيث تظل الكيانات المكتوبة بواسطة الإصدار الأقدم قابلة للقراءة بشكل صحيح)، ولكن أنواع أخرى من التغييرات (جعل السمة المفقودة أو الاختيارية مسبقًا إلزامية بدلاً من ذلك، وإضافة قيود أخرى، وما إلى ذلك) قد تتطلب شكل "ترحيل قاعدة البيانات" (ربما عبر Secure Data Connector) أو "الاختراق على مستوى التطبيق للتوافق القديم" إذا كان الترحيل غير ممكن.

قد لا يكون الترحيل ممكنًا، على وجه الخصوص، إذا كنت تحتاج إلى القدرة على العودة إلى إصدارات التطبيق السابقة، على سبيل المثال (في تلك الحالات تصبح العمليات الأخرى مشكلة، على سبيل المثال.تصبح إزالة القيود مشكلة تمامًا مثل إضافتها، نظرًا لأن الإصدار القديم قد لا يتمكن من التعامل مع البيانات المدخلة في الإصدار الجديد مما ينتهك القيود التي تمت إزالتها في الإصدار الجديد).

لذلك فهي ليست بالضرورة مشكلة بسيطة في الممارسة العملية، ولكن لا يزال من المفيد التفكير في الأمر بهذه الطريقة:لا يحتوي مخزن البيانات في حد ذاته على مخطط، فقط التطبيق الخاص بي و/أو المكتبات التي يختار استخدامها يفرض أي قيود مطلوبة على مستوى التطبيق على الكيانات الأساسية والتي، في حد ذاتها، لكل منها مجموعة عشوائية من السمات - "المخطط الناعم" ، مخطط على مستوى التطبيق، لا يوجد مخطط "فعلي" في طبقة البيانات الأساسية.