Yes, I'm glad you raised this Ara, there are a couple of different things I've been speculating about here:
(1) An isDirty() interceptor callback, to allow an application to
implement its own dirty checking algorithm
(2) A new property attribute; update="never|auto", to declare
"readonly" properties that are updated outside the application
(by a trigger, for example).
(3) A new property attribute; dirty-check="always|never" to allow
a property that isn't itself dirty-checked, but *is* updated
if other properties are dirty. (I am kinda ripping off a feature
of Castor here ;)
(4) Reintroduce dynamically generated SQL UPDATEs (which only
update dirty columns), as an option. I implemented this feature
at one stage, but the performance gains were not what you would
expect in my tests. However, it is worth having as an option.
I'd love to see #2, since there are quite a few things in my system that gets update by triggers, and I've been quite worried that these fields might get overwritten. #1 and #3 are nice to haves, but I don't have any immediate needs for these features. Ditto with #4.
-Mark
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
