Wie Datastore-und App Versionen funktionieren auf GAE/J

Question

Ein bereitstellen können mehrere Versionen der gleichen Anwendung auf GAE/J, aber wie sieht GAE/J mit der Tatsache auseinandersetzen, dass verschiedene Versionen können verschiedene Datenspeicher (und möglicherweise nicht kompatibel) Systeme?

Beispiel:

Angenommen, auf version 1 meiner Anwendung habe ich ein POJO wie (habe ich weggelassen das einige details aus Gründen der Einfachheit):

public class User {

  private String key;

  private String username;

  private Integer phoneNumber;

}

Nehmen wir nun an, dass an version 2, die ich verwenden möchte:

public class User {

  private String key;

  private String username;

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

}

Jetzt zwei Fragen:

1. Wenn ich die Bereitstellung von Versionen om GAE/J, was schema sehe ich in den Datastore?

2. Was ist mit den Daten?Wenn ich einen Benutzer hinzufügen auf version 2, ich sehe Ihre Daten auf der Datenspeicher version 1?

Answer 1

Zitieren die docs,

Im Gegensatz zu relationalen Datenbanken, die App Engine datastore ist nicht erforderlich, dass alle Entitäten einer bestimmten Art haben, die gleichen Eigenschaften.Die Anwendung können festlegen und durchsetzen Ihrer Daten Modell die Verwendung von Bibliotheken im SDK enthalten, oder seinen eigenen code.

Dies wurde auch bezeichnet als "soft-schema" -- datastore nicht wirklich do schemas, aber Sie können mehr oder weniger simulieren Sie ein paar sanfte Art von schema, die über application-level-code (Ihre eigenen oder in Bibliotheken).

Also, wenn Sie (über die Bibliothek oder in Ihrem eigenen code) durchzusetzen, eine Einschränkung, die sagt: "dieses Attribut muss vorhanden sein", und eine gewisse Person nicht tatsächlich das Attribut (weil es eingefügt wurde, basiert auf einer anderen "soft-schema", zum Beispiel eine andere version der app), dann erhalten Sie, was auch immer Ausnahme Ihre Anwendung-level-code oder die Bibliothek wählt, um zu verwenden, um anzuzeigen, dass ein Verstoß gegen diese weiche Randbedingung, an dem Punkt, in dem die Beschränkung aktiviert ist.

Wenn Sie express keine solchen Einschränkungen, dann ein Attribut fehlt, wird entweder ein Standard-Wert geliefert, indem Sie den code oder die Bibliothek, oder sonst ein "default", die ich glaube, ist in der Regel null in Java-bzw. None in Python.

Beachten Sie, dass unterschiedliche Versionen der app verwenden möglicherweise unterschiedliche Laufzeiten (einige können werden Java und andere Python) und die unterschiedlichen Laufzeiten wird noch verwenden Sie die gleichen datastore, sodass die Java vs Python Unterscheidung ist nicht entscheidend.

In Ihrem speziellen Beispiel (ohne Verzug zur Verfügung gestellt und keine Aussagen gemacht über die obligatorische Anwesenheit) ich würde erwarten, dass das hinzufügen einer Benutzer von entweder-version wird es sichtbar von den anderen, mit fehlenden Parametern, wie gesehen null (aber möglicherweise gibt es Einschränkungen, die ich bin mir nicht bewusst, in welchem Fall eine Ausnahme sollte sich ergeben, wenn eine Bibliothek zu validieren versucht, diese Einschränkungen und sieht Sie als verletzt).

Im Allgemeinen, ich würde nicht sorgen über das hinzufügen von "optional" - Attribute (diejenigen, die rechtmäßig fehlen/null/None, oder haben einen expliziten Standard in diesen Fällen so, dass die Personen geschrieben, die von der älteren version noch korrekt lesbar), aber auch andere Arten von änderungen (so dass eine zuvor fehlende oder optionales Attribut obligatorisch statt, das hinzufügen von weiteren Einschränkungen, etc.) erfordern eine form der "migration der Datenbank" (vielleicht über den Sicheren Daten-Anschluss) oder auch "application level-hacks für legacy-compatibility", wenn eine migration ist nur undurchführbar.

Migration möglicherweise nicht durchführbar, insbesondere wenn Sie die Möglichkeit zum rollback zur vorherigen app-Versionen, zum Beispiel (in der Tat in diesen Fällen andere Operationen problematisch werden, z.B.entfernen Einschränkungen wird nur als problematisch, da Sie Sie hinzufügen, da die alte version möglicherweise nicht in der Lage zu deal mit die Daten in die neue ein, die gegen Einschränkungen, die entfernt wurden, in der neuen version).

Es ist also nicht unbedingt ein problem, aber in der Praxis doch noch hilft, denken Sie an es auf diese Weise:der datastore per se kein schema, nur meine app und/oder die Bibliotheken, die es wählt, um zu verwenden durchzusetzen, was constraints sind erwünscht, auf app-Ebene auf die darunter liegenden Einrichtungen, die sich per se jeder wirklich haben eine beliebige Anzahl von Parametern -- "soft-schema", application-level-schema, keine "eigentliche" - schema in der zugrunde liegenden Daten-layer.