Hibernate version:
2.1.7

I have to write an Interceptor.findDirty(...) method, but I'm not sure about the semantics.

The JavaDoc says
.

Ok, but I want to check only one property and leav dirty checking of the others to hibernate.

Is it find to just return

1. null if the property hasn't changed, so hibernate checks the others
2. an array with only one int pointing to the one property I checked and hibernate updates the whole entity anyway?

TIA
Ernst

hi ernst_pluess,

i don't know exactly, but i've taken a look at SessionImpl.flushEntity() in line 2482 and it seems to me, that when you return an int[], hibernate won't do the default-handling ... hibernate expects you to do the dirty-handling ...

I hope i don't overlooked a "interceptor.findDirty"-call ...

Not nice .. but a workaround could be to do the default-handling on your own ... problem is, that you need to now the persister of the current entity ...

gtx
curio

Yes, I had a look at the code as well.

Calling the Hibernate dirty checking isn't possible, since it requires the session :-(.

On the other hand, up on doing an SQL update, hibernate updates all the fields anyway (AFAIK at least if dynamic-update is not set to true).

Does hibernate always update all fields to the new values once it knows the entity is dirty?

TIA
Ernst

BTW: Changing the hibernate code to merge the result of findDirty and it's own dirty checking doesn't seam to be very difficult.

yes, i think hibernate uses all fields for update if at least one has changed ...

if i'm right, in the persisters-update-method the dirtyField[] is only used in case of optimistic-lock = true ....

if you're trying it, please write the result ... it would be interesting to know if we're right :)

Or you can use the "onFlushDirty"-method if it's possible for you ... problem is, that this method seems not to be called for replicated entites (what ever that means :) ) ...

gtx
curio

btw: isn't it possible to get the Session from something like the 'HibernateSession-Util'-Class?

Yes, but I doubt whether this works in this case. Dealing with entities in different sessions doesn't seam to be a good idea.

HTH
Ernst

sorry for asking stupid ... but why 'different session'? You could use the currentSession ... as long as you only need it to determine the changed properties ....?

if i'm right, the session isn't used until it its passed to the Type.isDirty-method ... so there should be no problem using it ...

or ... if it's the only thing that happens during hibernate-default-handling you can call the "Type.isDirty"-method on your own .. then you should be able to figure out which property has changed ...

gtx
curio

I think I have to be more specific about what I want to do.

For every entity managed by Hibernate I want to check a property and maybe change an other one up on flushing. Acutally I would have to implement the preFlush() method. Unfortunately I need the old state in order to decide whether to change the other property.

After all I found the following rater hacky way to solve the problem:
I do the property checking and changing in the findDirty() method, but return null. Since the currentState values passed into findDirty are the original objects of the session, this will work the same way as a preFlush() but gives me the chance to compare current and old values. By returning null Hibernate will find the changes itself.

Guess this isn't the original intention of findDirty(). I'm also aware that I souldn't code again implementations but stik to the interface. I hope I can get rid of the whole Interceptor with Hibernate3.

WDYT?
Ernst

hmmm ....

just a question ...
does hibernate set your changed property back to the object if you change a property (currentState[]) in findDirty (in case of immutable types)?
Or is that no problem in your case?

I know this will be done using "onFlushDirty" and returning 'true' ... but sure, this method might not be called if your entity hasn't changed 'for hibernate' .... (is it possible that you have to change a property even if currentState and previousState are equal?)

On the other hand ... if you know, that your property "a" has to change if "b" is set to "hello" ... why not do this before saving the object? Or, if that change should be transparent to the application you could let hibernate access that changed field by "access=field" and use a different property for your "getter" and "setter" methods?! ... just a 'wild idea' ;-)

gtx
curio