如何在 Google App Engine 上使用 Objectify 创建多对多关系?
我找不到任何有关在 Google App Engine 上使用 Objectify 在对象之间建立多对多关系的适当方法的文档。
谁能解释一下如何做到这一点?我需要为此创建一个新的“加入”类吗?效率如何?
I can't find any documentation on the appropriate way to make a many-to-many relationship between objects using Objectify on Google App Engine.
Can anyone explain how to do this? Do I need to create a new "join" class for this? How efficient will it be?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您需要支持哪些类型的查询?
最简单的解决方案是:
然后,给定一个 StoredObject,您可以调用 objectify.get(StoredObject.class,storedObject.getRelatedIds()) 来获取所有相关的 id。
为了加速我自己的应用程序中的一些查询,我创建了一些连接类。费用来自写入时(您必须维护连接),但读取时是具有连续结果的单个索引扫描!
What kinds of queries do you need to support?
The simplest solution is:
then, given a
StoredObject
, you can callobjectify.get(StoredObject.class, storedObject.getRelatedIds())
to fetch all the related ids.To speed up some queries in my own app I did create a few join classes. The expense comes at write-time (you have to maintain the joins) but then read-time is a single index scan with consecutive results!
这不是在 Objectify 中映射多对多关系的最佳方法。最好的方法是创建一个映射关系的实体。例如,假设您有两个对象 A 和 B,并且它们以某种方式关联。您可以创建一个类似于以下内容的类:
然后您可以创建一个 Link 实体来建模关系。这会自动映射一对一或多对多关系
This is not the best approach to map many to many relationships in Objectify. The best way is to create an entity that maps the relationship. For example, suppose you have two objects A and B, and they are associated in a certain way. They you could create a class similar to:
Then you may create a Link entity to model a relationship. This automatically maps one to one or many to many relationships
我已经通过 Objectify 4.0 使用这种方法解决了问题:
I've solved using this approach with Objectify 4.0 :
让我们考虑一下一对多;如果你想让一个对象A“有很多”对象B,只有两种方法可以做到:
关系方法:让每个B都指向A。当你有A0并且想要所有相关的B时 关系方式:让每个B
NoSQL / ObjectStore 方式:让 A 有一个字段,其中包含指向 B 的指针(键)列表。请注意,这种方式还允许 B 按特定顺序排列(尽管 GAE/Java 文档相反。)
哪一个最好取决于。 ObjectStore方式受到对象大小的限制。关系方式存在一个微妙的问题,除非 A 和所有 B 都在同一个实体组中,并且您在事务中执行祖先查询(或者即使它不在事务中),您保证会得到所有指向该 A 的 B。但是,如果 A 和 B 跨越实体组,则您有可能(尽管不太可能)得到不满足查询谓词的 B,或者错过了一个B: https://developers.google.com/appengine/articles/transaction_isolation
现在来说说很多很多:我曾经读过一个故事,描述了在太空上厕所;有四种组合:太空飞船内/外以及两种上厕所的组合。对于在船外(穿着太空服)和消除固体的最后组合,唯一的答案是“没有优雅的方式”(也是文章的标题):http://settlement.arc.nasa.gov/CoEvolutionBook/SPACE.HTML#There 没有优雅之路
...这也是 GAE 中多对多关系的答案。您可以使用连接类来构建它们,并且连接的每一端都可以使用查询或键列表来实现。
Let's think about one-many for a moment; if you want an object A to "have many" object B-s, there are only two ways to do it:
The Relational Way: make each B point at the A. When you have the A0 and want all the B-s that relate to it, just query for the B-s which point to the given A0.
The NoSQL / ObjectStore way: make A have a field that holds a list of pointers (Keys) to the B-s. Note that this way also allows the B-s to be in a particular order (despite the GAE/Java docs to the contrary.)
Which one is best depends. The ObjectStore way is limited by the size of an object. The Relational way is subject to a subtle problem in that unless A and all the B-s are in the same Entity Group and you do an Ancestor Query in a Transaction (or maybe even if it isn't in a Transaction) you are guaranteed to get all of the B-s which point to that A. However if the A and B-s span Entity Groups, it is possible (though perhaps unlikely) that you will get a B that does not satisfy the query predicate, or miss a B that does: https://developers.google.com/appengine/articles/transaction_isolation
Now for many-many: I read a story once that described going to the toilet in space; there were four combinations: inside/outside a space ship and the two kinds of going to the toilet. For the last combination of being outside the ship (in a space suit) and eliminating solids, the only answer was "there ain't no graceful way" (also the title of the article): http://settlement.arc.nasa.gov/CoEvolutionBook/SPACE.HTML#There Ain't No Graceful Way
... and that is also the answer to many-many relationships in GAE. You can build them using a join class and each side of the join could be implemented with a query or a list of Keys.