Come funzionano le versioni Datastore e App su GAE / J

Question

È possibile distribuire diverse versioni della stessa applicazione su GAE / J, ma in che modo GAE / J gestisce il fatto che versioni diverse possono utilizzare schemi di datastore diversi (e possibilmente incompatibili)?

Esempio:

Supponi che nella versione 1 della mia applicazione ho un POJO come (ho lasciato fuori i vari dettagli per motivi di semplicità):

public class User {

  private String key;

  private String username;

  private Integer phoneNumber;

}

Ora supponiamo che nella versione 2 voglio usare:

public class User {

  private String key;

  private String username;

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

}

Ora due domande:

1. Se distribuisco entrambe le versioni su GAE / J, quale schema vedrò nel Datastore?

2. E i dati stessi? Se aggiungo un utente sulla versione 2, vedrò i suoi dati sul Datastore della versione 1?

Answer 1

Citando i documenti ,

  

A differenza dei database relazionali, l'app   L'archivio dati del motore non lo richiede   tutte le entità di un determinato tipo hanno il   stesse proprietà. L'applicazione può   specifica e applica il suo modello di dati   utilizzando le librerie incluse con l'SDK,   o il proprio codice.

Questo è stato anche chiamato " soft schema " - il datastore in realtà non esegue schemi, ma è possibile simulare più o meno alcuni tipi di schemi software tramite il codice a livello di applicazione (il proprio o nelle librerie).

Quindi se tu (tramite la libreria o nel tuo codice) imponi un vincolo che dice " questo attributo deve essere presente " e una certa entità non ha effettivamente quell'attributo (perché è stato inserito in base a un " soft schema " diverso; ad esempio una versione diversa dell'app), otterrai l'eccezione che il codice o la libreria a livello di applicazione sceglie di utilizzare per indicare un violazione di questo vincolo soft, nel punto in cui viene controllato il vincolo.

Se non esprimi tali vincoli, un attributo mancante avrà un valore predefinito fornito dal tuo codice o dalla tua libreria, oppure un " default default " ;, che credo sia di solito < => in Java o null in Python.

Nota che versioni diverse dell'app possono utilizzare runtime diversi (alcuni possono essere Java e altri possono essere Python) e i diversi runtime continuano a utilizzare lo stesso archivio dati, quindi la distinzione Java vs Python è non cruciale qui.

Nel tuo esempio specifico (senza alcuna impostazione predefinita fornita e nessuna asserzione fatta sulla presenza obbligatoria) mi aspetterei che l'aggiunta di un utente da una versione lo renderà visibile dall'altra, con attributi mancanti visti come None (ma potrebbe esserci essere vincoli di cui non sono a conoscenza, nel qual caso dovrebbe verificarsi un'eccezione quando una libreria tenta di convalidare tali vincoli e vede che vengono violati).

In termini generali, non mi preoccuperei di aggiungere " opzionale " attributi (quelli che possono legittimamente mancare / <=> / <=>, o avere un default esplicito in quei casi, in modo che le entità scritte dalla versione precedente siano ancora leggibili correttamente), ma altri tipi di modifiche oppure l'attributo facoltativo è obbligatorio invece, l'aggiunta di altri vincoli, ecc.) può richiedere una forma di " migrazione del database " (forse tramite Secure Data Connector) o " hack a livello di applicazione per compatibilità legacy " se una migrazione è semplicemente impossibile.

La migrazione potrebbe non essere fattibile, in particolare, se si richiede la possibilità di eseguire il rollback alle versioni precedenti dell'app, ad esempio (in effetti in questi casi altre operazioni diventano problematiche, ad esempio la rimozione dei vincoli diventa altrettanto problematica dell'aggiunta, poiché la vecchia la versione potrebbe non essere in grado di gestire i dati inseriti nel nuovo che viola i vincoli che sono stati rimossi nella nuova versione).

Quindi in pratica non è necessariamente un semplice problema, ma aiuta comunque a pensarlo in questo modo: il datastore di per sé non ha schemi, solo la mia app e / o le librerie che sceglie di usare impongono qualunque vincolo si desideri a livello di app su entità sottostanti che, di per sé, hanno ciascuna un set arbitrario di attributi - " soft schema " ;, schema a livello di applicazione, no " effettivo " schema nel livello dati sottostante.