大桌子亲子
如果我有像categoryA这样的pojo ->子类别A-->书本关系。 子类别 A 是父类别 A 的子类别。书是子类别A的子类别 所有内容都位于同一实体组内
在这种情况下，如果我需要将“书籍”移动到另一个子类别 B，则 。我需要删除subcategoryA和categoryA，并重新创建categoryA ->子类别A-->没有书？并重新创建categoryb ->子类别b-->书，其他书，其他书3？
if have i have pojo like categoryA -> subcategoryA--> book relationship.
subcategoryA is child of parent categoryA. book is child of subcategoryA
in this case, everything is inside same entitygroup
if i need to move 'book' to another subcategory-B. i need to delete subcategoryA and categoryA, and recreate categoryA -> subcategoryA--> without book ? and recreate categoryb -> subcategoryb--> book ,other-book, other-book3 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果“book is child of subcategoryA”并且您通过将 subcategoryA 的键添加到 book 的键路径来对此进行建模，则您需要删除/重新创建 book，或者需要使用与 subcatagoryA 最初具有的键相同的键创建 subcatagoryB。这将影响属于子类别 A 子类别的所有其他书籍。
这是因为（引用 appengine 文档：“在数据存储中创建实体时分配完整的键，并且其任何部分都不能更改。”）。
对我来说，这两种解决方案似乎都非常棘手，我建议您重新考虑您的设计。例如，您可以将 subcatagoryA 的键存储为单独属性内的单独字段。这也有缺点，您可以通过对数据进行非规范化并将子类别 A 的（部分）数据直接存储在书中来部分解决。
[编辑]
回答你的问题：小型实体组的缺点是不能使用事务。这是否是一个问题取决于...您是否真的需要书籍+（（子）类别上的交易。当您想要更改非规范化数据的某些内容时，就会出现更大的非规范化问题。为此，您可以提出一个像这样的方案：
If 'book is child of subcategoryA' and you have modeled this by adding subcategoryA's key to book's key-path, you either need to delete/recreate book, or you need to create a subcatagoryB with the same key as subcatagoryA originally had. This would affect all other books that were child of subcatagoryA.
This is because (citing appengine docs: "The complete key is assigned when the entity is created in the datastore, and none of its parts can change.").
Both solutions to me seem as quite tricky, and I suggest that you rethink your design. For instance, you could store subcatagoryA's key as a seperate field inside a separate property. This has down-sides as well, which you could partly solve by denormalizing your data and storing (part of) subcatagoryA's data directly INSIDE book.
[EDIT]
In response to your question: the disadvantage of small entity groups is that you can not use transactions. Whether this is a problem depends on...whether you really need transactions on books+((sub)categories. A bigger problem of denormalization comes up when you want to change something of your denormalized data. For this, you could come up with a scheme like this: