Why aren’t entities of the same kind implicitly in the same entity group when they don’t have a parent (they are root entities)? Does that mean if I want to do for example batch operations of writing data from MySQL to HRD:
db.put([Person(name=person.name) for person in cursor.execute("SELECT * FROM person")])
and I have to use transaction for this reason:
Note: A batch call to db.put() or db.delete() may succeed for some entities but not others. If it is important that the call succeed completely or fail completely, you must use a transaction, and all affected entities must be in the same entity group.
Source: https://developers.google.com/appengine/docs/python/datastore/entities#Batch_Operations
I need to create a common root parent key, which does not exists as a real entity only for the purpose of transaction?
parent_key = db.Key.from_path('Human', 'human')
db.put([Person(parent=parent_key, name=person.name) for person in cursor.execute("SELECT * FROM person")])
Entities of the same kind are not implicitly in the same entity group because it would generally give terrible performance for the majority of use cases.
While not entirely accurate, you can think of entity groups as a way to control sharding. Entities in the same group are stored in close physical proximity (ie on the same server), allowing all entities to be operated on transactionally, but also limiting performance on that entity group. Parent relationships within entity groups are not restricted to kind, parent entities need not be in the same kind as children.
Most of the time, entity groups would contain various entities of different kinds, which logically belong together because transactions tend to be based on the group. For example an Account might be the parent of a bunch of Transactions, or a BlogPost might be the parent of a bunch of Comments.
Putting all entities of a Kind under the same parent would prevent them from being properly parented for other operations where they really need to be in transactions.
In your case, it’s probably better not to run the operation in a transaction, and have extra code to handle failure cases.