# > (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.
#
Is it possible that there was no performance gain because updating
multiple objects could not share the same prepared statement? Were
prepared statements used at all?
Maybe a new property attribute to group properties could help, which
can be used to limit the number of possible update statements. A user
could define an object that could use two update statements, one for
all fields, and another for a selected group of fields (those that
change more frequently).
But then, maybe this could be made adaptive as well... Hibernate could
learn what fields are changed frequently and which are not, and then
decide what and how many update statements to generate... and still take
advantage of batching and the prepared statement cache.
Also, I just looked at the source code, and it seems that batch updates
aren't used for versioned objects. Is this because some JDBC driver's don't
support the update count array returned from executeBatch()? (like Oracle,
which does support getUpdateCount() though). We've used batch updates
with the Oracle JDBC driver, and it does provide much better performance
than non-batched updates.
Thx
Andrej
