I've read some questions and articles about many to many relations in the google datastore but I'm still not sure which is the most efficient way in my case: I have a User which references N CollectionOfThings. A CollectionOfThings can reference M users. Both, M and N are very small. I except no more then 5. (Nature of my application). The user object is fetched almost in every request. The other object not. I need to query from an instance of CollectionOfThings all users and from a user all instances of her CollectionOfThing instances.
So I see to possible implementations:
CollectionOfThings has a List of Users. User has a collection of CollectionOfThings. Both ends of the relation are NOT annotated with @Load. If I need the objects of one the relatin parts I load them with ofy().load().keys();
I use a relation object which I can query ofy()....filter("user", ...) and vice versa.
Now the big question is: What is the most efficient way in perspective of data store read operations?
Start with the simplest/easiest approach, you can always migrate later. From what you describe, I would start with Set<Ref> fields pointing in both directions. You can use @Load groups so that the loads don't happen by default but you still have the facility available. Make sure to update both ends of the relationship in a transaction.
Another option, assuming the User<->CollectionOfThings relationship is symmetric bidirectional, is to only keep the Set of keys/refs on one side and @Index it. This has the advantage that you don't need a transaction to keep the bidir relationship in sync. It has the disadvantages that you use queries to follow the relationship in the inverse direction; those queries will be eventually consistent; it costs extra to maintain those indexes.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments