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.
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 hibernate, i.e. updating only modified columns.
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?

Thanks in advance

On the long run, it makes a lot of sense to use an open-source framework instead of rolling our your own solution because you don't have to spend money maintaining it.

Now, before I answer all your questions, you should know that Hibernate has a 70% market share, there are tons of tutorials available on the Internet as well as StackOverflow answers.

Now, back to your questions.

Hibernate supports dynamic updates. However, by default, all columns are updated using a statement that can be cached. So, for entities where you don't have many indexes, the statement caching might outperform dynamic updates. For tables where you have many indexes, you should use the @DynamicUpdate support offered by Hibernate.



Hibernate supports statement batching, and even reordering so that cascading does not affect batch inserts and updates.



Hibernate uses PreparedStatements exclusively, so you can reuse execution plans since you're using Oracle.



I'm aware that special care must be taken for PostgreSQL, so that might be the case for Oracle too.



Hibernate uses FK columns for managing associations. Even if you might drop the constraint in the D (which might be a bad choice), Hibernate will still work.



No. But you can use @DynamicUpdates as indicated above.



That's up to you do decide if an entity should use @DynamicUpdate or not (the default). Hibernate does not use any AI to figure this out.



Think about it! Hibernate is used by millions of developers every day, on Oracle, SQL Server, PostgreSQL, MySQL, DB2, etc. That being said, it comes with almost anything you'll ever need for a typical OLTP application.



You can customize almost anything in Hibernate. Even the way entity state transitions are handled, CRUD statements, identifier generators, etc.

We also integrate Pull Requests from our community as well. It's an open source project after all.



There are many more features that Hibernate offers and you haven't mentioned them. Check out this list of awesome features Hibernate comes with and you might not find them in other JPA providers.

All in all, Hibernate is a great choice.

Hi vlad,

Thanks a lot for your answers. That is very useful information for our evaluation.

The task at the moment is showing what other JPA-implementations can and cannot do in those specific areas (smart update in this one case).
In general it is agreed around here that switching to JPA would be highly beneficial for various reasons (like community support and easier on-boarding of new developers).
It will also very likely be that any JPA-implementation will support everything we might need in functionality and most normal business cases will see essentially the same performance.
Its only in the corner cases, where we have put extra effort into our framework, where significant differences (mainly in performance) can be expected.
The decision is a big one (lots of existing code to rewrite and test). Thats why we are expected to dig a little deeper to show that those corner cases will not end up biting us.
Everywhere are tutorials on how to use it (at most with some pitfalls/best practices hints) but little info on what exactly goes on under the hood.
I haven't found nearly as much information on the topic of smart updates by searching the net or this board, as in your answer.

* are there features implemented in this area that were not touched upon in the list above but could guide a comparison?
> There are many more features that Hibernate offers and you haven't mentioned them.

That question was intended for the narrow topic of smart updates

* are there hooks in the Hibernate framework that would allow one to implement these without having to directly patch core Hibernate code?
> You can customize almost anything in Hibernate.

That question too was specifically geared toward smart updates.
For example a callback-method with a list of bit-arrays. One for each entity in a batch with 1=modified 0=unmodified for all fields
would be expected to return the bit-array to ultimately use for the batch-statement.
The idea being that implementing an existing callback-hook is the easiest. Using a pull-request to add such a hook is more involved.
And a pull-request with a full implementation change is the biggest one in terms of how much one needs to dive into Hibernate internals.

> even reordering

Those are also very useful and informative blog entries. Assuming they are still up to date some observations :

- hibernate.jdbc.batch_versioned_data
- Set this property to true if your JDBC driver returns correct row counts from executeBatch().

We ran into that too, because the Oracle thin-driver does not (maybe with the 12er version we don't use yet). We use Oracle-style-batching instead (for optimistic locking).
If this is not adressed/adressable in Hibernate at the moment it might be a problem (i.e. non-batched updates).

Its not quite clear how dynamic-update interacts with @OptimisticLocking.ALL (which is matching what we are doing now).
Would we still have all columns in the WHERE clause, even if fewer are in the SET-clause?

It leaves open the original question : what happens in bulk updates when each row has a different set of modified columns? JDBC-batching only works with one statement for all rows.

> all columns are updated using a statement that can be cached.
> Hibernate uses PreparedStatements exclusively, so you can reuse execution plans since you're using Oracle.

What does it entail if a (dynamic) statement is not cached but still uses PreparedStatement? I assume Hibernate relies on or can be made to use the statement-cache of the driver
and connection-pooling.
Is there caching beyond that involved? Our framework remembers mainly the SQL-Text and the batch-size (auto-maximizing through use with an upper cap).
We also remember alternative updates (we call them slim updates), keyed on the modified field-bit array.

* 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

> Even if you might drop the constraint in the D (which might be a bad choice)

I didn't mean removing the constraint but the constrained column from the statement, if it wasn't changed.
This in connection with the next question about general AI, which you say Hibernate does not employ.

Thanks once again for your help

I guess you can use a custom Hibernate type for that. Check out this example on how you can write a custom type for a JSON type. Because Hibernate does not support DB-specific ARRAY types, a custom type is needed.



For Oracle 12, hibernate.jdbc.batch_versioned_data works. For older versions, it does not.



I think you meant batch updates, right? For bulk updates, it would be an UPDATE query that you execute. For batch updates, dynamic updates would work as long as you modify the same properties in every batch step. Otherwise, the PreparedStataemnt cannot be batched. I think you should give it a try according to your business use case.



Hibernate is built on top of JDBC. Therefore, statement caching is addressed by the JDBC driver. Connection pooling can be provided by an external framework, like HikariCP, which is probably the best choice. If you don't use dynamic updates, Hibernate will use a single PreparedStatement for every entity. If you use dynamic update, then you need to rely on the JDBC Driver for caching statements.

What about HHH-3360?

Did you read the comments?

For some reason I thought the OP want batching for earlier versions of Oracle. But anyway, the fix is usable for 11g for example, right?

There's no fix in Hibernate for this because this is an Oracle Driver issue. You have this issue with plain JDBC and Oracle 11.

Yep, true, I used the wrong word for it. I meant the patch which enables Hibernate to properly do the batch building even though the driver returns wrong row count.

The patch got rejected for it was using proprietary API.