Como fazer versões de armazenamento de dados e aplicativos de trabalho em GAE / J

Question

Pode-se implantar várias versões do mesmo aplicativo em GAE / J, mas como lida GAE / J com o fato de que versões diferentes podem usar diferentes Datastore (e possivelmente incompatíveis) esquemas?

Exemplo:

Suponha que na versão 1 do meu aplicativo eu tenho um POJO como (Eu tenho deixado de fora os vários detalhes para fins de simplicidade):

public class User {

  private String key;

  private String username;

  private Integer phoneNumber;

}

Agora, suponha que na versão 2 Quero usar:

public class User {

  private String key;

  private String username;

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

}

Agora duas perguntas:

1. Se eu implementar ambas as versões om GAE / J, o esquema irá vejo no armazenamento de dados?

2. E sobre os dados em si? Se eu adicionar um usuário na versão 2, vou ver seus dados no armazenamento de dados da versão 1?

Answer 1

os docs ,

Ao contrário de bancos de dados relacionais, a App armazenamento de dados do motor não exige que todas as entidades de um determinado tipo têm a mesmas propriedades. O aplicativo pode especificar e impor seu modelo de dados usando bibliotecas incluídas com o SDK, ou seu próprio código.

Esta também tem sido referido como "esquema soft" - o armazenamento de dados realmente não do esquemas, mas você pode mais ou menos simular algum tipo suave de esquema via código de nível de aplicação (o seu possuir, ou em bibliotecas).

Então, se você (através da biblioteca ou no seu próprio código) impor uma restrição que diz "este atributo deve estar presente", e uma certa entidade não realmente ter esse atributo (porque foi inserido baseado em um diferente " esquema soft", por exemplo, uma versão diferente do app), então você vai obter qualquer exceção seu código em nível de aplicativo ou escolhe biblioteca usar para indicar uma violação desta restrição macio, no ponto em que a restrição é verificada.

Se você não expressam tais restrições, em seguida, um atributo que está faltando ou terá um valor padrão fornecido pelo seu código ou biblioteca, ou então um "default default", que eu acredito que é geralmente null em Java ou None em Python.

Note que diferentes versões do aplicativo podem utilizar diferentes tempos de execução (alguns podem ser Java e outros podem ser Python) e os diferentes tempos de execução irá ainda usar o mesmo armazenamento de dados, de modo que o Java vs Python distinção é não crucial aqui.

No seu exemplo específico (sem padrão fornecido e nenhuma afirmação feita sobre a presença obrigatória) Eu esperaria que a adição de um usuário a partir de qualquer versão irá torná-lo visível a partir do outro, com atributos ausentes vistos como null (mas pode haver restrições que eu não estou ciente de, caso em que uma exceção deve resultar quando um tenta biblioteca para validar essas restrições e vê que eles estão sendo violados).

Em termos gerais, eu não iria se preocupar em adicionar atributos "opcionais" (aqueles que podem ser legitimamente ausente / null / None, ou ter um padrão explícita nesses casos, para que as entidades escritos pela versão mais antiga ainda estão correctamente legível ), mas outros tipos de mudanças (fazendo um anteriormente em falta ou atributo opcional ser obrigatória em vez disso, a adição de outras restrições, etc) pode exigir uma forma de "migração de banco de dados" (talvez por meio do Secure Data Connector) ou "hacks nível de aplicativo para compatibilidade com legado "se uma migração é apenas inviável.

A migração pode não ser viável, em particular, se você precisar a capacidade de reversão para versões de aplicativos anteriores, por exemplo (na verdade nos casos de outras operações tornam-se problemático, por exemplo, a remoção de restrições torna-se tão problemático como adicioná-los, uma vez que o antigo versão pode ser incapaz de lidar com dados inseridos no novo que viola restrições que foram removidos na nova versão).

Portanto, não é necessariamente um problema simples, na prática, mas ainda ajuda a pensar nisso desta maneira: o armazenamento de dados por si só não tem esquema, só o meu aplicativo e / ou as bibliotecas que escolhe usar impor o que quer que as restrições são desejados no nível de aplicativo em entidades subjacentes que, per se, cada um realmente tem um conjunto arbitrário de atributos -. "esquema soft", o esquema de nível de aplicativo, nenhum esquema "real" na camada de dados subjacente