Entity groups in Google App Engine Datastore

Question

So I have an app that if I'm honest doesn't really need transactional integrity (lots of updates, none of them critical). So I was planning on simply leaving entity groups by the wayside for now. But I'd still like to understand it (coming from a relational background).

The way I see it, all queries for my app will be on a user by user basis. Therefore I do not need to group any higher than a user entity, according to the docs recommendations. But I wasn't planning on having a specific user entity, instead relying on UserProperty in the entities themselves.

The way I see it, if I want transactions (on a per-user basis), I will need some kind of root user entity as the parent of all entities that are part of the hierarchy of her data, no matter how thin this entity would actually be i.e. basically no properties.

Is this correct?

Apologies for verboseness, I only really pinged what schema-less actually meant in practice tonight...

Answer 1

You are essentially correct. You need to group them if you want transactional capability. However, you can group several entities together without creating an actual root entity, in the sense of an entity in the datastore. You instead create a sort of virtual root entity. One important use case of this feature is the ability to create a child object before you create it parent.

You can create an entity with an ancestor path without first creating the parent entity. To do so, you create a Key for the ancestor using a kind and key name, then use it as the parent of the new entity. All entities with the same root ancestor belong to the same entity group, whether or not the root of the path represents an actual entity.

That quote is from the same doc you linked to.

Answer 2

The way I see it, if I want transactions (on a per-user basis), I will need some kind of root user entity as the parent of all entities that are part of the hierarchy of her data, no matter how thin this entity would actually be i.e. basically no properties.

I wouldn't just create a root user entity and throw everything in its entity group. Think about what you need transactions for. If you have no properties on your user entity, what would you be using it in transactions with?

I don't know about your data, but let's assume it's a blog system and you have users, posts and comments. The Post model holds a number_of_comments so you don't have to count them. You might want transactions to ensure when you create a comment, the number_of_comments property can be updated safely.

In this case, it would be an unnecessary overhead to have all of a users posts and comments in a single entity group. Instead, you can post the comments in the same entity group as the post they belong to. There would be no need to put the posts into the same group as a user, and in fact this would be a bad idea, since comments posted in any of a users post would all be contending to write the same entity group.

I wrote a short article about entity groups on my blog today. You might find it useful.