Wenn Sie zu localhost: 4321/_ah/admin navigieren, können Sie den sdk datastore viewer nutzen, wo Sie sehen, dass jede Art von Entity ein KEY-Feld und ein NAME/ID-Feld hat;
Unabhängig davon, ob Sie long, String oder Key als @PrimaryKey verwenden, gibt es eine ID/Name-Spalte mit einer Zeichenfolge/Nummer und eine KEY-Spalte mit dem codierten Schlüssel für diese ID. Wie in anderen Posts erwähnt, enthält diese Kodierung {md5s, höchstwahrscheinlich} die Appspot-Anwendungs-ID, den vollständig qualifizierten Klassennamen des Datenobjekts und was immer Sie als @PrimaryKey angeben.
Die einzige Zeit, die Sie jemals direkten Zugriff auf dieses Feld wünschen, ist, wenn Sie absolut nicht interessiert, was die Daten benannt sind, {wenn Sie Ihr Programm benötigen, um zu finden, aber Menschen werden nicht danach suchen Wörter in ein Textfeld eingeben} oder wenn Sie mehrere Objekte des gleichen Typs und Namens haben möchten {vielleicht mit einer Version int?}, dann sollten Sie die Syntax des codierten Schlüssels verwenden. Sowohl KEY als auch ID sind in der db vorhanden, unabhängig davon, ob Sie ein Feld in Ihre Klasse einfügen. Mit der codierten Schlüsselsyntax können Sie nur auf diesen Wert zugreifen.
Außerdem gibt es einen verfügbaren Geschwindigkeitsbonus für Anwendungen, die codierte Schlüssel verwenden ... Es gibt nur zwei Arten von Abfragen: SELECT * und SELECT _ _ key _ _ {Leerzeichen zum Anzeigen von zwei _}. Für große Datenmengen in AJAX-Anwendungen besteht die einzige effiziente Möglichkeit zum Paginieren von Daten darin, alle Schlüssel auszuwählen, sie an den Client zu senden und den Client nach 0-> X Anzahl der Datensätze fragen zu lassen, Links für die anderen X-> zu erstellen Y Ergebnisse, und fragen Sie den Server mit dem ersten Satz von codierten Schlüsseln für vollständige Daten, analysieren Sie die Antwort in nette kleine Listen und vermeiden Sie das Laden von 397 Server-Datenobjekten, die nicht sofort nützlich sind.
Das Senden von codierten Schlüsseln über den Draht kann etwas mehr Bandbreite erfordern als uncodierte Schlüssel (es sei denn, Sie sind so lange damit beschäftigt, Dinge zu benennen, wie ich bin!}; aber es rasiert diese CPU-Zyklen auf appengine, macht deine Quoten glücklicher, und die App von jedem läuft nur einen Bruchteil schneller!
Dieser Schlüssel wird, selbst wenn er nicht aufgetrennt wird, nur so sensible Daten offenlegen, wie Sie einen Primärschlüssel erstellen. Ihr App-Passwort ist nicht betroffen, ebenso wenig wie Benutzerpasswörter in einem vernünftigen Datenmodell. Das einzige, was möglicherweise {BIG} austreten könnte, ist eine Benutzer-E-Mail-Adresse, wenn Sie die angegebene Benutzerklasse für die Authentifizierung verwenden, oder die Klassennamen, die Sie in Ihrer Quelle verwenden.
... Grundsätzlich können nur Informationen verfügbar sein, die bereits bei der Anzeige einer oder mehrerer Firebug-Anfragen verfügbar sind.
Interessieren Sie sich für die gleiche Frage, aber in Python? – dfrankow