Comment les versions de magasin de données et d'applications fonctionnent-elles sur GAE / J?

Question

On peut déployer plusieurs versions d'une même application sur GAE / J, mais comment GAE / J gère-t-il le fait que différentes versions peuvent utiliser différents schémas de banque de données (et éventuellement incompatibles)?

Exemple:

Supposons que sur la version 1 de mon application, j'ai un POJO comme (j'ai laissé de côté plusieurs détails pour des raisons de simplicité):

public class User {

  private String key;

  private String username;

  private Integer phoneNumber;

}

Supposons maintenant que sur la version 2, je souhaite utiliser:

public class User {

  private String key;

  private String username;

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

}

Maintenant deux questions:

1. Si je déploie les deux versions de GAE / J, quel schéma verrai-je dans le magasin de données?

2. Qu'en est-il des données elles-mêmes? Si j'ajoute un utilisateur sur la version 2, mes données s'afficheront-elles sur le magasin de données de la version 1?

Answer 1

Citation de les documents ,

  

Contrairement aux bases de données relationnelles, l'application   Le magasin de données du moteur n’exige pas que   toutes les entités d'un type donné ont le   mêmes propriétés. L'application peut   spécifier et appliquer son modèle de données   en utilisant les bibliothèques incluses avec le SDK,   ou son propre code.

Cela a également été appelé & "; schéma souple &"; - La banque de données ne pas vraiment les schémas, mais vous pouvez plus ou moins simuler un type de schéma souple via un code de niveau application (le vôtre ou dans des bibliothèques).

Donc, si vous (via la bibliothèque ou dans votre propre code) appliquez une contrainte indiquant & "cet attribut doit être présent &" ;, et qu'une certaine entité ne possède pas cet attribut (car il a été inséré sur la base d'un & "schéma souple &", par exemple une version différente de l'application, vous obtiendrez alors l'exception que votre code au niveau de l'application ou la bibliothèque choisira d'utiliser pour indiquer violation de cette contrainte souple, au moment où la contrainte est vérifiée.

Si vous n'exprimez pas de telles contraintes, alors un attribut manquant aura soit une valeur par défaut fournie par votre code ou votre bibliothèque, soit un & "défaut par défaut &", qui, je crois, est habituellement < => en Java ou null en Python.

Notez que différentes versions de l'application peuvent utiliser différentes exécutions (certaines peuvent être Java et d'autres peuvent être Python) et que les différentes exécutions utiliseront toujours le même magasin de données. Par conséquent, la distinction Java / Python est pas crucial ici.

Dans votre exemple spécifique (sans valeur par défaut ni affirmation sur la présence obligatoire), je pense que le fait d'ajouter un utilisateur d'une version à l'autre la rend visible de l'autre, les attributs manquants apparaissant sous la forme None (mais Je ne suis pas au courant de contraintes, auquel cas une exception devrait se produire lorsqu'une bibliothèque tente de valider ces contraintes et constate leur violation.)

De manière générale, je ne voudrais pas ajouter & "; facultatif &"; attributs (ceux qui peuvent légitimement être manquants / <=> / <=>, ou avoir une valeur par défaut explicite dans ces cas, de sorte que les entités écrites par l'ancienne version sont toujours lisibles correctement), mais d'autres types de modifications (rendant un élément précédemment manquant) ou attribut facultatif obligatoire, ajouter d’autres contraintes, etc.) peut nécessiter une forme de " migration de base de données " (peut-être via le connecteur de données sécurisé) ou & "; piratages au niveau de l'application pour compatibilité si une migration est tout simplement irréalisable.

Par exemple, la migration peut ne pas être réalisable si vous avez besoin de la possibilité de revenir aux versions précédentes de l'application, par exemple (dans ce cas, d'autres opérations deviennent problématiques, par exemple, la suppression des contraintes devient aussi problématique que leur ajout. Il est possible que la version ne puisse pas traiter les données saisies dans la nouvelle qui violent les contraintes supprimées dans la nouvelle version).

Donc, ce n'est pas nécessairement un problème simple dans la pratique, mais il est toujours utile de penser de cette façon: le magasin de données en tant que tel n'a pas de schéma, seule mon application et / ou les bibliothèques qu'il choisit d'utiliser appliquent les contraintes souhaitées à niveau de l'application sur les entités sous-jacentes qui possèdent chacune un ensemble d'attributs arbitraire - & "schéma souple &", schéma au niveau de l'application, pas de & "nombre réel &"; schéma dans la couche de données sous-jacente.