Reputation: 5323
Google Cloud Datastore / App Engine Datastore allows entities to have Key properties. What is special about them?
The reason I ask is that they seem to store extra seemingly redundant data in the datastore (such as App ID). What features would I miss out on if I were to roll my own and save my key references as strings instead?
Upvotes: 2
Views: 678
Reputation: 41099
The main difference is that a key contains all the information on the ancestors. So if you have an entity Photo, which is a child of entity Album, which is a child of entity User, having a key for Photo entity is more convenient as you can simply call .get(key)
, while otherwise you need to know IDs of Album and User to reconstruct the key.
If you objects already have IDs of parent entities, or if you don't use parent-child relationships, storing IDs takes less space and requires less bandwidth (e.g. smaller JSON objects to transfer), which may or may not be significant for your app.
Upvotes: 2
Reputation: 39824
An advantage of using the KeyProperty
is the ability to directly navigate to the respective entity from the referring entity in the Datastore browser pages where these properties are recognized and have links associated to them (but only if they aren't repeated properties).
If using Key ID
s instead as mentioned in Jeff's answer to reach the respective entity one has to copy the ID, switch to the other entity type and search/filter by the respective ID, which can be tedious.
If using some other encoding of the key reaching the respective entity is even mode complicated as either the ID or the Key must first be decoded.
Upvotes: 2
Reputation: 16563
There isn't anything particularly special about a key property. It is just a convenient way of getting a related entity by calling .get()
on the stored key.
Note that storing a key does not store an app id. If you back up your data store and restore it to a different app, then all your stored keys work fine because they do not depend on the app id.
In my app, it is more convenient for me to store the numeric id of the key (in an integer property) instead of the key itself. Since I know the kind, it is easy to use get_by_id()
instead of get()
.
How would you store your keys as strings? I don't expect you to see any significant size reduction in doing that but you could try it each way and compare entity size using the trick here.
Upvotes: 1