I have implemeneted the Complex Validations using Interceptor pattern
Yet, I got the problem is the during the callback onFlushDirty, the field previousState is NULL. Which result the DeltaSet cannot calcaulate correctly.

I am using Session Bean to do the update

The problem is caused by incoming parameter uom is serialized before. ( queried by another EJB remote method ). That mean the uom is come from another hibernate session and that session is closed.

The problem can be simply repeated by

The problem may be solved by using sess.replicate method instead of sess.update. But replicate will update all the object graph instead according to cascade setting which I want.

Does anyone have a better solution on it ?

Anyone have idea ?

of course, hibenate does not know the current db state in the case of update()!

hiebrnate has a strange behaviour in cascade collections saving new entities.

situation: entity E has a cascade=all collection of F's.

after loading E, adding a new F into it's collection and updating E, hibernate calls onFlushDirty on the freshly created F instance, and later on calls an onSave, too.

in the onFlushDirty call the previous state is null. i've not seen it documented, and it's not intuitive either. (at least for me)

Why exactly is it not intuitive that an insert would not have previous state?

And if you say "because its already been saved", please stop and go read the documentation.

i meant it's not intuitive that hibernate calls onFlushDirty on an entity that is currently being inserted. then what is onSave for?

what is intuitive for me is one callback method for update situations and another one for save situations. now we have one for save and one for save/update.

and still it would be ok, if it were documented in that way. but:

"Called when an object is detected to be dirty, during a flush."

this implies for me that the object is already known to hibernate, so onFlushDirty is only called for update()'s. again, it could be only my bugous thinking...

but if you accept a subjective opinion, i have a feeling that the wording of the documentation is written in the context of the hibernate implementation, not in the context of generic o/r mapping. which implies some knowledge about the hibernate code, without which many things are not clear or behave unexpected.

again it's just an opinion.



i've met this attitude so many times in this project... you don't give a thing on user feedback. which is probably reasonable guessing the noise made by newbies, but still it shouldn't be the way...

the less you listen to the annoyance of users, the more noise will be generated when unexpected behaviour is seen.

don't misunderstand me, still a huge thanks for hibernate!!! i really appreciate the free work you do on this project!!!

i think i have found a bug in ValidationInterceptor. CollectionPropertyDelta.anyChangeDetected is implemented like this:

it should be


should not it?

i tried to post a comment on the wikipage, but i did not manage...