Hello,

I have a Customer class being persisted by Hibernate 2.1.2 to an Oracle 9i database with the select-before-update option on. This object will be used in "detatched" mode; in other words its not for a web application but instead for a swing desktop application. Of course this means that the object will not be loaded and saved in the same session.

I am trying to implement Interceptor.onFlushDirty to generate e-mails that list the changes made to the customer. However, whenever I call saveOrUpdate(customer), the previousState array is empty. My log file indicates that when I call saveOrUpdate, a select is issued to the database to obtain the current record before onFlushDirty is called. I figured that since Hibernate knows about the previous state as a result of that select, it should be able to populate the previousState array.

Am I missing something? Any help would be greatly appreciated.

Thanks!
Patrick

Well, the problem is that the snapshot retrieved by select-before-update might not contain exactly the kind of objects you expect. For example, instead of a customer, you get a customer id and instead of a collection you get a null.

So we don't expose this "unresolved" snapshot to the application.

Ah, that makes sense...I forgot that the select-before-update feature won't always load the entire object.

So in the case where I load an object in one session and save it in another, how can I get the previousState array to contain the current values for the entity?

Currently, there is no way. Talk to Steve, he owns this problem :)

OK, I have two more questions for you then:

1. Is it possible to somehow obtain the information that Hibernate gets from the select-before-update? I do realize that the information is only supposed to be used internally (and it would be somewhat of a hack if I had access to it), but I thought I'd ask anyway. :)

2. Another way to implement this would be to implement Lifecycle for these objects and manually load them from the database when saving and do a compare from there. Do you see any issues with that (besides the fact that it will slow down the application)? I'm not crazy about that idea, but creating an e-mail with the changes made to these objects is a requirement for my application.

Thanks!
Patrick

(1) not in Hibernate 2.1 (It is doable in Hibernate3 CVS)
(2) why dont you just do:




if it is just for one place in your system?

Actually, I will have to do this for most of my entities. It will be somewhat tedious, but it does seem like the simplest solution. (Perhaps I will make it an aspect so that I can apply it across all of the DAOs that need to generate subscriptions).

I'm just curious...where can I see Hibernate 3 in CVS? I looked there, but I only saw Hibernate and Hibernate2.

One more item (not to change topics on you, but thought I'd ask while I have your attention :) ...are you accepting patches for 2.1.2? I would like to submit a fix for a null pointer exception in AbstractEntityPersister.java. It happens when calling getCurrentPersistentState. Line 1249 calls getVersionType() to set the version field in the PreparedStatement, but it is making the assumption that the object is versioned. If the obect is not versioned, a NPE is thrown. All that has to be done is to check to make sure that the object is versioned (same way that is done in lock(), line 1188).

Thanks for your help,
Patrick

Then write a generic method which takes Object ;)



Hibernate2 module, v22branch



Nasty! Please submit a patch to JIRA. TIA