Google Appengine: Is this a good set of Entity groups?

Question

I'm trying to wrap my head around Entity groups in a Google AppEngine app. I understand them as a whole, but since it seems like you cannot change relationships after creating the object. And I have a big data migration, I want to try to fix it for the first time.

I create an Art site where members can register as a regular regular member or as one of several non-polymorphic Entity types (Artist, Venue, Organization, ArtistRepresentative, etc.). Artists, for example, may have a work of art, which, in turn, may have other relationships (Gallery, media, etc.). All of these things are linked through Links, and I understand that you don’t need Entity groups to use links easily. However, some of the Recommendations MUST exist, so I am considering Entity groups.

From the docs: "A good rule of thumb for groups of entities is that they should be the size of one user data volume or less."

However, I have a couple, hopefully yes / no.

Question 0: It seems that you do not need Entity groups to complete transactions. However, since Entity Groups are located in the same Big Table region, this helps to reduce consistency issues and race conditions. Is this a fair look at entity groups and transactions together?

Question 1: When a child entity is persisted, do any parent objects get implicit access or persist? those. if I create an Entity Group with a Member / Artist / Work item, if I save an Artwork object, update / access the Member and Artist objects? I would not have thought, but I'm just sure.

Question 2: If the answer to question 1 is yes, is access / update distributed only along the way and does not affect other children. those. if I update Artwork, no other child of Art of Member is updated.

Question 3: Assuming that it is very important that the member and the related object of the account type exist when the user signs up and that only the user will update their member and the associated Entity account type, does it make sense to insert them into Entity Groups together ?

i.e. Member / Executive, Member / Organization, Member / Venue.

Similarly, if only the user can update Artwork objects, does it make sense to include them as well? Note. Media / Gallery / etc, which are links to Artwork, can be associated with a large number of Work, and not only with the user (that is, many or many relationships).

It makes sense to have all the user bits in the entity group if it works as I suspect (ie Q1 / Q2 - “no”), since they will all be in the same BigTable area. However, adding Artwork to an entity group seems like it might violate the “keep it small” principle and honestly, you may not need to be in transactions other than maintaining bandwidth / relay when users upload cover images.

Any thoughts? Am I going wrong with Entity Groups?

Answer 1

• 0: you need entity groups for transactions between multiple objects.
• 1: change / access to children does not change / does not support parent
• 2: N / A
• 3: Sounds reasonable. I feel that entity groups should not be used unless you need transactions between them.

There is no need to have the Artwork as a child for permission purposes. But if you need a transactional modification (including, for example, creating and deleting), this might be better. For example: if you delete the account, you delete the user object, but before deleting this child you get DeadlineExceeded or the server crashes. Now you have an orphanhood. If you have more than 1000 pieces for the artist, you must delete them in batches.

Good luck