Как работают версии Datastore и App на GAE/J

Question

Можно развернуть несколько версий одного и того же приложения на GAE/J, но как GAE/J имеет дело с тем, что разные версии могут использовать разные Datastore (и, возможно, несовместимые) схемы?

Пример:

Предположим, что на версии 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

Цитирование the docs,

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

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

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

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

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

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

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

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

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