We are currently evaluating a switch from a self-implemented persistence framework to JPA.
Part of that process is comparing special features of our framework with what Hibernate, EclipseLink or OpenJPA offer in that area.
I will be searching myself (for example this board) but would also like to ask in case someone can point me directly to the right information.
Also because I will be on vacation the next two weeks. Its Ok if the analysis ist postponed till afterwards, but maybe with this request I can already get some info before then.
Note : We only use Oracle-DBs, so there might be some assumptions below that are oracle-centric
So this question is about smart updates in OpenJPA, i.e. updating only modified columns.
How is this handled :
* Batch/bulk updates (each row might have a different set of modified columns)
will there be multiple statements or one with the superset of columns?
individual statements would defeat the batching-purpose, we think
* will the statements be kept as prepared across transactions and reused for the same subsets?
rebuilding and reparsing would be unwanted overhead
* will special consideration be used for partitioned tables?
updating a partitioning field would mean DELETE+INSERT when the partition changes, so reducing the other columns has no effect so use full update
* will columns with constraints (foreign key and check) be treated special?
removing those has bigger impact, than run-of-the-mill fields, since it avoids the check
* will columns with indexes be treated special?
not updating them can skip the full index maintance
apparently oracle can detect if the value doesn't change and will optimize this, but skipping it entirely is still better, we think
* will the mechanism try to apply common sense?
for example if the statement still contains > 66% (configurable) of all columns and the remainder are all run-of-the-mill simply switch to the full update
* will the mechanism try to keep the number of different statements to a mangeable few?
i.e. less then all permutations of all fields, say a maximum of 5, so as not to flood the database statement cache causing excessive reparsing.
requires finding the closest inclusive match.
* if any of these features are not there, have there been analysises of them with the decision not to implement them?
if so what arguments were made against them?
* are there hooks in the framework that would allow one to implement these without having to directly patch core code?
* are there features implemented in this area that were not touched upon in the list above but could guide a comparison?
I had posted this question to a hibernate forum two weeks ago, before my vacation. Please ignore that line.
I had found that hibernate has a dynamic-update=true option. I haven't yet found if OpenJPA has such a feature. The questions above assume that there is something like that.