Question

如果我有以下一组实体：

A --> (unowned) B
  \
   --> (owned) List<C>

D --> (owned) List<E> --> (owned) List<F> --> (unowned) A
  \
   --> (unowned) H

G --> (unowned) H
  \
   --> (unowned) D
  \
   --> (unowned) B
  \
   --> (unowned) A
  \
   --> (unowned) F
  \
   --> (unowned) F

如果我在交易中触摸所有这些对象，我会计算4个实体组（A，B，D，H）这应该是允许的（根据文档，最多可以有5个）。

所以，2个问题： 1）你如何获得/创造它们是否重要？即是

C c = new C(a);
a.getCs().add(c);

以某种方式使用两个独立的实体组，即使它是父/子关系？或者G有两个不同的F值的事实是两个实体组还是一个？

2）访问对象时有多深？即如果我也有

D --> (owned) List<K> --> (owned) List<L> --> (unowned) M

appengine是否在交易中访问的实体组列表中包含M，即使我没有访问K，L或M？

我从概念的角度对我的对象模型非常满意（没有appengine我很确定我会再次以相同的方式设计它）但是我应该像其他人在这里建议的那样创建一个GenericObject什么是某种程度的父母？

或者，鉴于这在数据库领域非常简单，有多少人放弃了DataStore for Cloud SQL 6个月？（也许最后一次对于stackoverflow来说太主观了，但这是一个真正的问题）

更新

在浏览通过将所有内容调试后生成的日志后，我可以看到在某些时候我得到以下行：

24634 [1419746043@qtp-647750325-2] DEBUG DataNucleus.Persistence - Performing reachability algorithm on object with id "com.google.appengine.api.datastore.Key:D("alex@hotmail.com")"

然后是从该根实体开始可以访问的每个对象的大量检索。因为这包括一堆无主的实体（也就是说，他们不使用任何被访问的实体到他们的父母）我想这是导致我的交易失败的原因，而Q2的答案似乎是'无处不在“

所以... Q3 - 我该如何防止这种行为。请注意，我调用makePersistent（D）以保留已修改的F的两个实例。

Answer 1

一些注意事项：

所有高级数据存储API（JDA / JPA / Objectify）都建立在low-level api之上。它们不能比低级API做得更多。如果您想了解数据存储区，您应该了解低级API。
实体之间的关系基于一个实体，该实体具有一个具有另一个实体的密钥的属性。简单地说：实体包含另一个实体的ID。
您只需从实体中删除关键属性即可破坏实体关系。没有参考完整性，因为您将在SQL世界中使用：您可以删除关系任一侧的实体而不受约束。
实体组基于祖先关系，并且没有关注上面第2点中提到的实体关系。祖先关系基于键：子键将包含所有父键的键。
< / LI>
由于祖先关系基于密钥，因此只能在创建实体时建立。由于密钥是不可变的，因此以后无法更改。
实体组的写/更新限制为1 write / s。因此，将所有实体放在一个通用GenericObject下是一个坏主意。您应该非常小心如何设计实体组，因为它们会影响性能。好的起点是将每个用户实体作为实体组的根。
实体组旨在定义事务范围（基本上它意味着这些实体驻留在同一服务器上，因此写入限制），并且您不应该使用它们来在实体之间建立逻辑关系。
< / LI>

Answer 2

我设法通过在jdoconfig.xml中添加以下内容来解决问题：

<property name="datanucleus.persistenceByReachabilityAtCommit" value="false"/>

这在http://www.datanucleus.org/products/datanucleus/performance_tuning.html

中有记录

如果有人想留下评论为什么这是必要的，或者可能为什么我的对象模型是错误的，我会非常感激，因为我是JDO和appengine的新手。

AppEngine如何计算事务的实体组？

2 个答案: