mnimer / dphibernate

Automatically exported from code.google.com/p/dphibernate
0 stars 0 forks source link

Entities already present on the client should not be reloaded #42

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Given a typical parent-child relationship, accessing parent.child() will 
correctly lazy-load the child object from the server.

However, a subsequent call to child.parent() will trigger another load of 
parent, despite it already being present on the client.

We should be smarter about this, and only load single instances of objects to 
the client.

Original issue reported on code.google.com by martypit...@gtempaccount.com on 6 Jul 2010 at 2:13

GoogleCodeExporter commented 9 years ago
Similarly, note the following issue:

parent.child.parent != parent; //  true.

Original comment by martypit...@gtempaccount.com on 6 Jul 2010 at 3:12

GoogleCodeExporter commented 9 years ago
Has this been integrated so far ?
Would be awesome !

Original comment by Loopster...@googlemail.com on 23 Sep 2010 at 5:18

GoogleCodeExporter commented 9 years ago
@Loopster212 Nope.  It's a pretty major architecture change.  It'll come, but 
in a later version.

Original comment by martypit...@gtempaccount.com on 23 Sep 2010 at 5:32

GoogleCodeExporter commented 9 years ago
Hey Marty thanks for your quick response!

Too bad ... but If you guys need support feel free to tell me.
At the moment i'm relaunching a big business application for solar surveillance.
Dp hibernate is a part of it.
Before i used Pimento, but due to security reasons, i had to switch and no lazy 
loading is no option =).

"parent.child.parent != parent; //  true."

Any solution for that Problem, except managing and checking all received 
entities ?

Original comment by Loopster...@googlemail.com on 24 Sep 2010 at 11:34

GoogleCodeExporter commented 9 years ago
Not offhand.

On my large dpHibernate projects, I tend to use a BaseEntity class similar to 
the one I used in LazyOverflow:
http://code.google.com/p/lazyoverflow/source/browse/trunk/java/src/com/mangofact
ory/pepper/model/BaseEntity.java

If you're using that, then:

parent.child.parent.equals(parent); // true

It's not great, but it's a start!

If you end up writing something more complicated, feel free to share it! :)

Original comment by martypit...@gtempaccount.com on 24 Sep 2010 at 12:07

GoogleCodeExporter commented 9 years ago
Just thinking this through, and having a quick brain dump:

There are two main thoughts that spring to mind:

  * Inbound, received objects should be stored in a EntityStore - which is akin to a big ol' hashmap.

interface EntityStore {
  put(proxy:IHibernateProxy):IHibernateProxyDescriptor;
  contains(proxy:IHibernateProxy):Boolean;
  get(key:IHibernateProxyDescriptor):IHibernateProxy; 
  find(proxy:IHibernateProxy):IHibernateProxy; // overload of get
  evict(proxy:IHibernateProxy):IHibernateProxy; // Returns the evicted element
}

The concept of a key representing an IHibernateProxy already exists as an 
IHibernateProxyDescriptor.  Note - these names suck something awful.  Renaming 
is another big breaking change though.

The underlying hashmap must have weak keys to help facilitate garbage 
collection.

We need to check the entity store to see if the entity exists before going out.

The obvious place to do this is HibernateManaged.  However, that's a static 
call, which would make the entityStore a static reference - something we've 
been gradually moving away from, as it forces us down a road of tight coupling.

Given this, I think we should look at adding an system level registry:

DPHibernate.getEntityManager():EntityManager;
DPHibernate.registerEntityManager(entityManager:EntityManager);

Still not a huge fan of the approach - open to alternatives.

Sorry about the freeform nature here - just trying to brain dump while I have 
time.

Original comment by martypit...@gtempaccount.com on 24 Sep 2010 at 12:20

GoogleCodeExporter commented 9 years ago
The moment you load a lazy asossciation you just have to pass the required 
information to the "lazyload token".
In the resulthandler you use this Information to set the "Parent" on the 
child(s);

var token:AsyncToken = lazyloader.loadLazy('children',parentObj);
token.parent = parentObj;
token.mappedBy = 
DPMetaData.getInstance().getMappingData("parentObjClassName","objectNameToInizia
lize");
 token.addResponder(new mx.rpc.Responder(lazyAssocHandler,lazyLoadFaild));
...

Should work or ? 

Original comment by Loopster...@googlemail.com on 27 Sep 2010 at 1:27

GoogleCodeExporter commented 9 years ago
Will be resolved as part of entity manager in 3.0

Original comment by martypit...@gtempaccount.com on 15 Mar 2011 at 3:46

GoogleCodeExporter commented 9 years ago
For the time being I am comparing the uid of the child.parent and parent and 
overriding the parent.uid. Not a good solution but good enough to meet the 
deadline.
But i agree the lazy loading message should contain more informaton about the 
parent of the child.

Original comment by aarijhus...@gmail.com on 6 Jun 2011 at 7:33