如果我有以下一组实体:
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 个)。
所以,有两个问题: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 不知何故万物之父?
或者,鉴于这在数据库世界中非常微不足道,有多少人在 6 个月内放弃了 Cloud SQL 的 DataStore?(也许最后一个对于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 的两个实例。