Hi, 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. 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. * Does something like hibernates dynamic-update=true exist in OpenJPA? How is this handled : * batch 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-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 hibernate framework that would allow one to implement these without having to directly patch core hibernate code? * are there features implemented in this area that were not touched upon in the list above but could guide a comparison? * when using optimistic locking with all fields : will the WHERE-Part also be reduced (which would be wrong)? Thanks in advance -- View this message in context: http://openjpa.208410.n2.nabble.com/dynamic-updates-tp7589914.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
