I just discovered Gavin's blog this morning and found the following:

Especially, we are interested in the idea that a graph could be retrieved from the persistent store in one process, modified in another, and then have those modifications propagated back to the database in the first process, all with optimistic semantics.

I'm very interested in that also since I'm building a three tier Java application. What is the status on this? I've got some ideas how this could be done but I'm not sure what discussions have happened to date (you folks always seem to have these things figured out already :) )

Regards,
John

oh, Hibernate has been able to do this for years ;)

Ok. I must have read some of my pet features into that post :)

What I was hoping it meant was that you're considering ways to allow changes to distributed objects to be saved to the database without having to reload the data from the database first to see what changed and require version or timestamp fields for optimistic locking.

I've got ideas for supporting that if your interested...

Regards,
John

Hibernate can do this.

Cool! Can you give me some hints on where to look for this? I haven't discovered this in the documentation yet.

Thanks,
John

session.update(detachedObject)

Just want to make sure we are talking about the same thing. Here's my scenerio:

- I load a graph of objects in a session on the server.
- I pass the graph to the client, the session goes away.
- I make changes to the objects including adding and deleting objects in collections with cascade=all
- I pass the graph back to the server
- I create a new session
- I call session.saveOrUpdate(detachedRootObject)

Will Hibernate generate the SQL for only the objects that have changed and resolve the additions and removals from the collections without deleting and reinserting the elements? Can it do this without loading the data from the database first?

Regards,
John

yes. we are talking about the same thing.

This is, like, almost 2-year-old functionality ;)

I'm confused. We had issues with this not working in Hibernate 1.2. When we posted the issue, we were told to move 2.1 and use select-before-update (http://sourceforge.net/mailarchive/message.php?msg_id=6313475). Am I missing something?

Regards,
John

OK, in your wish list above you did not specify:

- track exactly which properties changed

There is no really good way to track changes to a graph of POJOs at that fine level of granularity. So if you need something that granular, checking against the database is the simplest way.

Sorry...I need to work on my specificity :(



It does take some extra work, but it can be done and I think the performance implications of avoiding the extra check against the database are worth considering it. If I had to implement this, I would do it this way:

1) Add property change events for each attribute on the POJO
2) When a property is first changed, record the original value in a Map
3) When items are added to and removed from collections, keep track of them also
4) When generating the SQL for updating the object, check the original values Map to determine what properties, if anything, has changed. The user could have an option of what to include the where clause to handle optimistic locking (pk only, pk + original values of changed fields, pk + original value of all fields).
5) Use the collection additions and deletions to determine how to reconcile dependent collections

I think I could implement steps 1, 2 & the first part of 4 in my own code now by using the Interceptor.findDirty() method. The part I need help from Hibernate is the collection stuff. If Hibernate could keep track of the additions and deletions to collections in it's collection proxies and use that to determine what changes were made to the collection, I think I'd be set. (Maybe you've added that already?)

I would think you could generalize this for all Hibernate users by either creating an interface that returned the original values of changed fields or adding an interceptor that captured changes to properties and kept track of the original value for them.

What are your thoughts?

Thanks,
John

eh??

exactly how are you planning to serialize these Maps between tiers??

Like ... what object would have a reference to them?

Each object would be responsible for them. I have an "AbstractDomainObject" that is the ancestor for each persistent class. I could add the following to it:



Each persistent class would then be required to fire property change events for any persistent properties -- like any good JavaBean should. The changes would be collected automatically.

Regards,
John

Gavin - is that not what hibernate 2(.1) does now ?
(just wondering since you did not answer that to johnu, so I would just like to help him see that he can actually do what he wants....)

Yes, Hibernate2 does (3) and (5).

The other stuff could probably be implemented by overriding EntityPersister.getCurrentState() in 2.1.

But we will certainly not do this in the Hibernate core, since it is just not "transparent persistence".