Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Jede Entität wird durch einen Schlüssel identifiziert, der innerhalb der Datastore-Instanz der Anwendung eindeutig ist und aus folgenden Elementen besteht:
Art: Die Art ist normalerweise der Name der Modellklasse, zu der die Entität gehört. Sie können dies jedoch in einen anderen String ändern, indem Sie die Klassenmethode _get_kind() überschreiben.
Kennung: Sie geben Ihren eigenen Schlüsselnamen als Kennung an oder lassen Cloud Datastore automatisch eine ganzzahlige numerische ID generieren.
Eigenen Schlüsselnamen angeben
Im folgenden Beispiel wird implizit ein Schlüssel mit einer Stringkennung unter Verwendung des benannten Parameters id erstellt:
Sie könnten alternativ den Schlüsselnamen direkt festlegen:
account.key=ndb.Key('Account','sandy@example.com')# You can also use the model class object itself, rather than its name,# to specify the entity's kind:account.key=ndb.Key(Account,'sandy@example.com')
ID für den Schlüssel in Datastore generieren lassen
Dieser Code zeigt, wie Sie eine automatisch generierte ID als Schlüssel verwenden können:
# note: no id kwargaccount=Account(username='Sandy',userid=1234,email='sandy@example.com')account.put()# account.key will now have a key of the form: ndb.Key(Account, 71321839)# where the value 71321839 was generated by Datastore for us.
Ancestor-Pfad im Schlüssel verwenden
Die Abfolge der Entitäten von einer Stammentität über die übergeordneten und untergeordneten Elemente bis zu einer bestimmten Entität bildet den Ancestor-Pfad.
Die übergeordnete Entität einer Entität, die übergeordnete Entität der übergeordneten Entität und so weiter sind deren Ancestors. Die Entitäten im Datastore bilden einen hierarchischen Schlüsselbereich, der der hierarchischen Verzeichnisstruktur eines Dateisystems ähnelt.
Der vollständige Schlüssel, der die Entität identifiziert, besteht aus einer Abfolge von Art/Kennungs-Paaren, die deren Ancestor-Pfad angeben und mit den Paaren der Entität selbst enden: Die Konstruktormethode für die Klasse Key akzeptiert eine Folge aus Arten und Kennungen und gibt ein Objekt zurück, das den Schlüssel für die entsprechende Entität darstellt.
Das folgende Beispiel zeigt einen Blogdienst, der Nachrichten nach Revision speichert.
Nachrichten sind unter Konten organisiert und Revisionen unter Nachrichten.
Im Beispiel sind ('Account', 'sandy@example.com'), ('Message', 123) und ('Revision', '1') Beispiele für Art/Kennungs-Paare.
Beachten Sie, dass Message keine Modellklasse ist. Sie dient nur zur Gruppierung von Revisionen und nicht zum Speichern von Daten.
Wie im Beispielcode gezeigt, wird die Art der Entität durch das letzte Art/Namens-Paar in der Liste angegeben: ndb.Key('Revision', '1').
Benannte Parameter verwenden
Sie können den benannten Parameter parent verwenden, um eine Entität direkt im Ancestor-Pfad anzugeben. Alle folgenden Notationen stellen denselben Schlüssel dar:
Bei einer Stammentität ist der Ancestor-Pfad leer und der Schlüssel besteht ausschließlich aus der eigenen Art und der eigenen Kennung der Entität:
sandy_key=ndb.Key(Account,'sandy@example.com')
Entität mit Ancestors angeben
So fügen Sie eine neue Nachricht mit übergeordneten Schlüsseln ein:
account_key=ndb.Key(Account,'sandy@example.com')# Ask Datastore to allocate an ID.new_id=ndb.Model.allocate_ids(size=1,parent=account_key)[0]# Datastore returns us an integer ID that we can use to create the message# keymessage_key=ndb.Key('Message',new_id,parent=account_key)# Now we can put the message into Datastoreinitial_revision=Revision(message_text='Hello',id='1',parent=message_key)initial_revision.put()
Für Schlüssel, die mit einem übergeordneten Element erstellt wurden, gibt die Methode parent() einen Schlüssel zurück, der die übergeordnete Entität darstellt:
message_key=initial_revision.key.parent()
Numerische Schlüssel-IDs verwenden
Sie können eine Entität erstellen, ohne eine ID anzugeben. In diesem Fall generiert der Datenspeicher automatisch eine numerische ID. Wenn Sie einige IDs selbst angeben und andere IDs von Datastore automatisch generieren lassen, ist die Anforderung der Eindeutigkeit bei den Schlüsseln möglicherweise nicht erfüllt. Reservieren Sie einen Nummernbereich, den Sie für die Auswahl von IDs nutzen können, oder verwenden Sie String-IDs, um dieses Problem ganz zu vermeiden.
Verwenden Sie die Klassenmethode allocate_ids() der Modellklasse, um einen ID-Bereich zu reservieren:
eine bestimmte Anzahl von IDs zuordnen
alle IDs bis zu einem bestimmten Maximalwert zuordnen
IDs zuordnen
So weisen Sie 100 IDs für eine bestimmte Modellklasse MyModel zu:
first,last=MyModel.allocate_ids(100)
So weisen Sie 100 IDs für Entitäten mit dem übergeordneten Schlüssel p zu:
first,last=MyModel.allocate_ids(100,parent=p)
Die zurückgegebenen Werte first und last sind jeweils die ersten und letzten zugewiesenen IDs (einschließlich). Damit können Sie Schlüssel so konstruieren:
Diese Schlüssel werden garantiert nicht vom internen ID-Generator des Datenspeichers oder zukünftigen Aufrufen an den internen ID-Generator zurückgegeben. Die Methode allocate_ids() prüft jedoch nicht, ob die zurückgegebenen IDs im Datenspeicher vorhanden sind. Sie interagiert nur mit dem ID-Generator.
So weisen Sie alle IDs bis zu einem bestimmten Maximalwert zu:
first,last=MyModel.allocate_ids(max=N)
Dieses Formular sorgt dafür, dass alle IDs kleiner oder gleich N als zugewiesen gelten. Die Rückgabewerte first und last geben den Bereich der von diesem Vorgang reservierten IDs an. Es ist kein Fehler, die bereits zugewiesenen IDs zu reservieren. In diesem Fall gibt first die erste ID an, die noch nicht zugewiesen wurde, und last die letzte zugewiesene ID.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eEntities in the Datastore are uniquely identified by a key, which includes a kind and an identifier, either specified by the user or automatically generated by Datastore.\u003c/p\u003e\n"],["\u003cp\u003eThe key identifier can be a string, set by the user, or an integer ID, automatically generated by Datastore, which can be chosen by either setting an \u003ccode\u003eid\u003c/code\u003e parameter or letting it be generated upon using \u003ccode\u003eput\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eEntities can have an ancestor path, forming a hierarchical structure similar to a file system, where the complete key includes a sequence of kind-identifier pairs representing the entity and its ancestors.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eallocate_ids()\u003c/code\u003e method can be used to reserve a range of numeric IDs for a specific model, ensuring unique key creation, and this can be done either by specifying a number of ID's or a max number.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eparent\u003c/code\u003e named parameter can be used to designate any entity in the ancestor path directly, offering flexibility in defining entity relationships and key structures.\u003c/p\u003e\n"]]],[],null,["# Creating and Using Entity Keys\n\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| python3\n|\n| /services/access). If you are updating to the App Engine Python 3 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/python-differences) to learn about your migration options for legacy bundled services.\n\nEach entity is identified by a key that is unique within the application's\nDatastore instance, and consists of the following:\n\n- **kind** . The kind is normally the name of the model class to which the entity belongs, but you can change this to some other string by overriding the classmethod `_get_kind()`.\n- **identifier** . You specify your own *key name* as the identifier or let Datastore automatically generate an integer numeric ID.\n\nSpecifying your own key name\n----------------------------\n\nThe following example implicitly creates a key with a string identifier\nusing the named parameter `id`: \n\n account = Account(\n username='Sandy', userid=1234, email='sandy@example.com',\n id='sandy@example.com')\n\n return account.key.id() # returns 'sandy@example.com'\n\nYou could alternatively set the key name directly: \n\n account.key = ndb.Key('Account', 'sandy@example.com')\n\n # You can also use the model class object itself, rather than its name,\n # to specify the entity's kind:\n account.key = ndb.Key(Account, 'sandy@example.com')\n\nLetting Datastore generate an ID to use for the key\n---------------------------------------------------\n\nThis code shows how to use an auto-generated ID as the key: \n\n # note: no id kwarg\n account = Account(username='Sandy', userid=1234, email='sandy@example.com')\n account.put()\n # account.key will now have a key of the form: ndb.Key(Account, 71321839)\n # where the value 71321839 was generated by Datastore for us.\n\nUsing the ancestor path in the key\n----------------------------------\n\nThe sequence of entities beginning with a root entity and proceeding from parent\nto child, leading to a given entity, constitute that entity's *ancestor path* .\nAn entity, its parent, parent's parent, and so on recursively, are the entity's\n*ancestors*. The entities in Datastore form a hierarchical key space\nsimilar to the hierarchical directory structure of a file system.\n\nThe complete key identifying an entity consists of a sequence of kind-identifier\npairs specifying its ancestor path and terminating with those of the entity\nitself. The constructor method for class `Key` accepts such a sequence of kinds and\nidentifiers and returns an object representing the key for the corresponding entity.\n\nThe following example shows a blogging service that stores messages by revision.\nMessages are organized under accounts, and revisions are under messages.\n\n\n class Revision(ndb.Model):\n message_text = ndb.StringProperty()\n\n`...` \n\n ndb.Key('Account', 'sandy@example.com', 'Message', 123, 'Revision', '1')\n ndb.Key('Account', 'sandy@example.com', 'Message', 123, 'Revision', '2')\n ndb.Key('Account', 'larry@example.com', 'Message', 456, 'Revision', '1')\n ndb.Key('Account', 'larry@example.com', 'Message', 789, 'Revision', '2')\n\nIn the sample, `('Account', 'sandy@example.com')`, `('Message', 123)`, and `('Revision', '1')`\nare all examples of kind-identifier pairs.\n\nNotice that `Message` is not a model class; it is used only as a way to group\nrevisions, not to store data.\n\nAs shown in the sample code, the entity's kind is designated by the *last*\nkind-name pair in the list: `ndb.Key('Revision', '1')`.\n\n### Using named parameters\n\nYou can use the named parameter `parent` to designate any entity in the ancestor\npath directly. All of the following notations represent the same key: \n\n ndb.Key('Account', 'sandy@example.com', 'Message', 123, 'Revision', '1')\n\n ndb.Key('Revision', '1', parent=ndb.Key(\n 'Account', 'sandy@example.com', 'Message', 123))\n\n ndb.Key('Revision', '1', parent=ndb.Key(\n 'Message', 123, parent=ndb.Key('Account', 'sandy@example.com')))\n\n### Specifying a root entity\n\nFor a root entity, the ancestor path is empty and the key consist solely of the\nentity's own kind and identifier. \n\n sandy_key = ndb.Key(Account, 'sandy@example.com')\n\n### Specifying an entity with ancestors\n\nTo insert a new message with parent keys \n\n account_key = ndb.Key(Account, 'sandy@example.com')\n\n # Ask Datastore to allocate an ID.\n new_id = ndb.Model.allocate_ids(size=1, parent=account_key)[0]\n\n # Datastore returns us an integer ID that we can use to create the message\n # key\n message_key = ndb.Key('Message', new_id, parent=account_key)\n\n # Now we can put the message into Datastore\n initial_revision = Revision(\n message_text='Hello', id='1', parent=message_key)\n initial_revision.put()\n\nFor keys that were created with a parent, the `parent()` method returns a key\nrepresenting the parent entity: \n\n message_key = initial_revision.key.parent()\n\nUsing Numeric Key IDs\n---------------------\n\nYou can create an entity without specifying an ID, in which case the data store\nautomatically generates a numeric ID. If you choose to specify some IDs and then\nlet Datastore automatically generate some IDs, you could\nviolate the requirement for unique keys. To avoid this, reserve a range of\nnumbers to use to choose IDs or use string IDs to avoid this issue entirely.\n\nTo reserve a range of IDs, use the model class'\n[`allocate_ids()`](/appengine/docs/legacy/standard/python/ndb/modelclass#Model_allocate_ids)\nclass method:\n\n- to allocate a specified number of IDs\n- to allocate all IDs up to a given maximum value.\n\n### Allocating IDs\n\nTo allocate 100 IDs for a given model class `MyModel`: \n\n first, last = MyModel.allocate_ids(100)\n\nTo allocate 100 IDs for entities with parent key `p`: \n\n first, last = MyModel.allocate_ids(100, parent=p)\n\nThe returned values, `first` and `last`, are the first and last IDs (inclusive)\nthat are allocated. You can use these to construct keys as follows: \n\n keys = [ndb.Key(MyModel, id) for id in range(first, last+1)]\n\nThese keys are guaranteed not to have been returned previously by the data\nstore's internal ID generator, nor will they be returned by future calls to the\ninternal ID generator. However, the `allocate_ids()` method does not check\nwhether the IDs returned are present in the data store; it only interacts with\nthe ID generator.\n\nTo allocate all IDs up to a given maximum value: \n\n first, last = MyModel.allocate_ids(max=N)\n\nThis form ensures that all IDs less than or equal to `N` are considered\nallocated. The return values, `first` and `last`, indicate the range of IDs\nreserved by this operation. It is not an error to attempt to reserve IDs already\nallocated; if that happens, `first` indicates the first ID not yet allocated and\n`last` is the last ID allocated.\n| **Note:** you cannot call `allocate_ids()` in a [transaction](/appengine/docs/legacy/standard/python/ndb/transactions)."]]