google-code-export / objectify-appengine

Automatically exported from code.google.com/p/objectify-appengine
MIT License
1 stars 0 forks source link

Objectify does not provide "managed" relationships in the way that JDO or JPA does #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
As you said in the wiki... 
I like managed relationships.. so I have added support for them. 

Lets say this:

class Person {
    @Id String name;
    Person friend;
}

now works exactly the same as this one:

class Person {
    @Id String name;
    Key<Person> friend;
}

The only difference is that in the first one the "friend" get fetched 
automatically when you get a 
Person, and when you put a Person with a friend != null, the friend has to be 
on the datastore (it 
doesn't put the child when you put the person), otherwise you get an "entity 
doesn't exists" 
exception.

No annotation needed. I made it to detect if the type is registered.
Collections also magically worked.

Please, review it for me, either if you won't include it to trunk.

All test passed and I have added a few more. Regards  

Original issue reported on code.google.com by gal.dol...@gmail.com on 1 Mar 2010 at 8:57

Attachments:

GoogleCodeExporter commented 9 years ago
There are a few problems with this approach... while managed relationships are 
nice, 
they tend to give you a very wrong idea of your applications performance and 
actual 
work - here, me getting ten persons by key will result in 1+10 gets. The first 
one to 
get the ten persons, and the others to get the friend objects. This can very 
quickly 
spiral out of control. This could have been 2 gets if the developer knows very 
clearly 
what they situation actually is. Can you see how this would go? If each Person 
has a 
mom and dad reference, trying to fetch 100 persons would fire 301 individual  
gets. 
Thats close to kill time in on the app engine, and general suicide in any app. 

Original comment by sudhi...@gmail.com on 4 Mar 2010 at 5:54

GoogleCodeExporter commented 9 years ago
Yes, I get your point, but this is an alternative to the Key<> approach, not a 
replacement... in my case I will 
always need the nested values, and the other approach make me write many extra 
lines of code, and also make 
me duplicate my data model in the client (with GWT).. but thats my case. 
Regards

Original comment by gal.dol...@gmail.com on 4 Mar 2010 at 6:05

GoogleCodeExporter commented 9 years ago
I'm not opposed to adding this behavior, and this patch is on the right track, 
but it's 
not quite right yet.  The save process is fine but the load process has a few 
problems:

 * It creates a new Objectify outside of the transaction context of the original object 
load.
 * If you load a collection with 100 objects, it will do 100 fetches instead of a single 
batch fetch.

To make this work correctly you will need to pass the "current" Objectify 
instance in 
to Transmog.load(), and that method will have to know if the data needs to be 
batch 
fetched into a set of POJO entities.  The nice thing is that you can do this up 
front for 
the entire array of key objects and this will work even if the array actually 
corresponds to an embedded array.  You don't need to touch any of the setter 
chains.

There are some issues surrounding the saving process that should be discussed 
on 
the mailing list, such as whether or not to do cascading saves.  If you want 
this 
feature in Objectify, please start a discussion so we can get the right set of 
behaviors 
and get them documented properly (as well as implemented properly).

Thanks!

Original comment by lhori...@gmail.com on 5 Mar 2010 at 5:51

GoogleCodeExporter commented 9 years ago
This feature is implemented in Objectify4

Original comment by lhori...@gmail.com on 16 Dec 2011 at 2:23

GoogleCodeExporter commented 9 years ago
Amazing!

Original comment by gal.dol...@gmail.com on 16 Dec 2011 at 2:26