实体组
我正在尝试使用谷歌应用程序引擎，并且缺少事务di框架。我正在尽我所能地实现它，但我一次又一次地遇到相同的异常： 无法在单个事务中对多个实体组进行操作。发现两个元素... 我已阅读文档 (http://code.google. com/appengine/docs/python/datastore/keysandentitygroups.html#Entity_Groups_Ancestors_and_Paths），但我似乎无法理解他们的含义。 基本上我想做的是：
我有一个对象列表。我想检查它们是否已经在数据库中。如果是，我将检查它们是否相等，如果不相等，则更新托管实例。否则我会保留该实体。 在我的对象循环（尚未持久化的对象）中，我使用 EntityMananger.find() 按 Id 查找实体。第二次出现错误。
我习惯于使用 spring/hibernate(JPA) 或 EJB3 环境，但我以前从未见过这种情况。谁能给我一个简单的解释，为什么我无法在同一交易中找到两个相同类型的实体？
不是寻找“如何”，而是寻找“为什么”...
I'm experimenting a bit with google app engine and the lack of a transaction di framework is missing. I'm implementing it as good as I can, but I'm hitting the same exception again and again:
can't operate on multiple entity groups in a single transaction. found both Element...
I have read the documentation (http://code.google.com/appengine/docs/python/datastore/keysandentitygroups.html#Entity_Groups_Ancestors_and_Paths) but I can't seem to get what they are implying.
Basically what I'm trying to do is this:
I have a list of objects. I want to check if they are already in the database. If they are, i will check if they are equal, if not, update the managed instance. Otherwise I would persist the entity.
In my loop of objects (not yet persisted objects), I use EntityMananger.find() to lookup the entity by Id. The second time around it gives an error.
I'm used of working with a spring/hibernate(JPA) or a EJB3 environment and I have not seen this before. Can anyone give me a simple explanation of why I can't do a find of 2 entities of the same type in the same transaction?
not searching for a how, but for a why...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实体组是一个简单的概念。 App Engine 中的实体有祖先。例如，您可以为书籍和作者建模。
作者：姓名->X和作者：姓名->Y是作者KIND中的两个实体。书是另一种 KIND（KIND 只是实体的逻辑分组）。书籍和作者之间的关系可以建模为祖先-子关系。
例如，
书：姓名->B1、B2 可能是由作者：姓名->X 编写的。因此，您将它们建模为：
作者：姓名->X 是两本书的父级：姓名->B1、B2。类似地，Book: name->B3 是由 Author:name->Y 编写的，因此可以将该关系建模为 Author:name->Y 是 Book:name->B3 的父级。
当您尝试进行图书类交易时，您不能同时在B1、B3和B3上进行交易。因为他们参与不同的祖先-孩子关系。每个祖先子关系都是一个实体组。您一次只能“锁定”一个实体组。
希望这能让事情变得清楚一些。
Entity groups are a simple concept. Entities in App Engine have ancestors. For e.g. you could model Books and Authors.
Author: name->X, and Author: name->Y are two entities in the Author KIND. Book is another KIND (KIND is just a logical grouping of entities). The relationship between Books and Authors can be modeled as a ancestor-child relationship.
E.g.
Book: name->B1, B2 could have been written by Author: name->X. So you modeled them as:
Author: name->X is a parent of both Book: name->B1, B2. Similarly, Book: name->B3 is written by Author: name->Y and so could model that relationship as Author:name->Y is a parent of Book:name->B3.
When you try to transact on Books kind, you cannot transact on B1,B3 and B3 together. As they participate in different ancestor-child relationships. Every ancestor child relationship is an Entity group. You can only "lock" on one entity group at a time.
Hope this makes things a little clear.
据我所知，GAE 数据存储会根据实体的层次结构自动对实体进行分组。例如，如果您有“用户”的概念，并且将所有其他对象类型（电子邮件、联系人等）设置为“用户”作为父关系，则 GAE 数据存储会将所有这些内容视为“用户”的一部分。同一组。如果与特定用户相关的数据似乎经常从特定位置提取，谷歌可以自动将其数据移动到更靠近该位置的农场，以优化数据检索速度。
困难在于，这意味着您必须将所有实体绑定到主要父实体，或者必须避免在绑定到不同父实体的对象之间进行事务。有时这并不是什么大问题：将联系人从一个用户帐户移动到另一个用户帐户并不是您期望在 Gmail 中作为原子事务发生的那种事情。其他时候，这可能是一个真正的阻力。
From what I remember, the GAE datastore automatically groups your entities based on their hierarchy. For example, if you have a concept of a User, and you make all of your other object types (email messages, contacts, etc.) have User as a parent relationship, the GAE datastore considers all of those things to be part of the same group. If data related to a particular user seems to be getting pulled from a particular location a lot, Google can automatically move their data to a farm nearer that location to optimize data retrieval speeds.
The difficulty is that this means you have to either have all of your entities be tied to a main parent entity, or you have to avoid doing transactions across objects that are tied to different parent entities. Sometimes this isn't a big deal: moving a contact from one user account to another is not the sort of thing you'd expect to have happen as an atomic transaction in Gmail. Other times it can be a real drag.