Как хранилище данных и версии приложений работают на 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. Если я разверну обе версии om GAE / J, какую схему я увижу в хранилище данных?

2. А как насчет самих данных?Если я добавлю пользователя в версии 2, увижу ли я его данные в хранилище данных версии 1?

Answer 1

Цитирование документы,

В отличие от реляционных баз данных, App Хранилище данных движка не требует, чтобы все объекты данного вида имели одинаковые свойства.Приложение может указывать и применять свою модель данных используя библиотеки, входящие в комплект SDK, или свой собственный код.

Это также упоминается как "мягкая схема" - хранилище данных на самом деле не делай схемы, но вы можете более или менее смоделировать какой-то мягкий вид схемы с помощью кода уровня приложения (вашего собственного или в библиотеках).

Итак, если вы (через библиотеку или в своем собственном коде) применяете ограничение, в котором говорится "этот атрибут должен присутствовать", а у определенного объекта на самом деле нет этого атрибута (поскольку он был вставлен на основе другой "программной схемы", например, другой версии приложения), то вы получите любое исключение, которое ваш код уровня приложения или библиотека решит использовать, чтобы указать на нарушение этого программного ограничения, в момент проверки ограничения.

Если вы не выражаете таких ограничений, то отсутствующий атрибут будет либо иметь значение по умолчанию, предоставленное вашим кодом или библиотекой, либо "default по умолчанию", которое, как я полагаю, обычно null на Java или None на языке Python.

Обратите внимание, что разные версии приложения могут использовать разные среды выполнения (некоторые могут быть Java, а другие - Python), и разные среды выполнения будут все еще используйте одно и то же хранилище данных, поэтому различие между Java и Python здесь не имеет решающего значения.

В вашем конкретном примере (без указания значения по умолчанию и без утверждения об обязательном присутствии) Я бы ожидал, что добавление пользователя из любой версии сделает его видимым из другой, с отсутствующими атрибутами, видимыми как null (но могут существовать ограничения, о которых я не знаю, и в этом случае должно возникнуть исключение, когда библиотека пытается проверить эти ограничения и видит, что они нарушаются).

В общих чертах, я бы не стал беспокоиться о добавлении "необязательных" атрибутов (тех, которые могут законно отсутствовать/null/None, или иметь явное значение по умолчанию в этих случаях, так что объекты, написанные более старой версией, по-прежнему корректно читаются), но другие виды изменений (превращение ранее отсутствовавшего или необязательного атрибута в обязательный, добавление других ограничений и т.д.) Могут потребовать "миграции базы данных" (возможно, через защищенный соединитель данных) или "взломов уровня приложения для обеспечения совместимости с устаревшими версиями", если миграция просто неосуществима.

Миграция может оказаться невозможной, в частности, если вам требуется, например, возможность отката к предыдущим версиям приложения (действительно, в этих случаях другие операции становятся проблематичными, напримерудаление ограничений становится такой же проблемой, как и их добавление, поскольку старая версия может быть не в состоянии обрабатывать данные, введенные в новой, что нарушает ограничения, которые были удалены в новой версии).

Так что на практике это не обязательно простая проблема, но все же помогает думать об этом таким образом:хранилище данных как таковое не имеет схемы, только мое приложение и / или библиотеки, которые оно выбирает для использования, применяют любые ограничения, требуемые на уровне приложения, к базовым объектам, каждый из которых, по сути, действительно имеет произвольный набор атрибутов - "программную схему", схему уровня приложения, без "фактической" схемы на базовом уровне данных.