> (1) An isDirty() interceptor callback, to allow an application to > implement its own dirty checking algorithm
Good idea. In some case simple equals() is not enough. Let the application have some sort of control, if needed. > (2) A new property attribute; update="never|auto", to declare > "readonly" properties that are updated outside the application > (by a trigger, for example). +1 > (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 ;) Not sure about this. If another setter method updates a field then that field is dirty. Dirty checking overhead shouldn't be that high. > (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. The reason updating only the dirty fields is important for me is that let's say I load only 3-4 fields of a big 20 field table (into a proxy class, but I would love to see a declarative approach instead of a proxy class), now I change one of these 3-4 fields and update(). Afaik Hibernate tries to save all 20 fields and many of them are null! Is that right? This feature is imho essential, but performance-wise it's not a big deal in most case but maybe effective if the table contains BLOB/CLOB or large varchar fields or when the database does a charset conversion on text columns. Ara. ------------------------------------------------------- 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
