hibernate-orm is missing some important Hibernate batch configuration options

Description

See https://quarkus.io/guides/hibernate-orm for current list and https://vladmihalcea.com/how-to-batch-insert-and-update-statements-with-hibernate/ for additional needed options, e.g.

• hibernate.order_inserts
• hibernate.order_updates
• hibernate.jdbc.batch_versioned_data

Is it planned to add them?

Workaround

Using persistence.xml

Implementation ideas

No response

[kay-horst]

As to hibernate.order_inserts: I have optimized bulk inserts by a factor of about 50 by using Hibernate batching in the case of entities without relations. This optimization is very important for the application.

However, for an entity type using @OneToMany, batching is not applied due to the entity types’ not being sorted, so that single INSERTs are being generated.

It would be good to be able to stick with application.yaml properties instead of having to revert to a persistence.xml.

My suggestion for a “salomonic” solution: Instead of adding this property, which seems to have problems in some cases, to the quarkus.hibernate-orm.* - path, introduce quarkus.jpa.properties.* (analogous to SpringData), where one can set native JPA provider properties, which in the case of Hibernate will translate:

quarkus.jpa.properties.foo.baz -> hibernate.foo.baz

Thus, hibernate-orm can stick to a limited set of “opinionated” properties based on the module developers’ reasoning, but the application developer has the liberty to apply arbitrary properties at their own risk. If it is made clear in the documentation, that using this puts the application developers at their own risk, it should not be too much of a hassle.

[Sanne]

Right, and same for the others.

FWIW:

• AvailableSettings.ORDER_UPDATES is always enabled in Quarkus, as we believe it’s the better option and has no known drawbacks.
• ORDER_INSERTS is meant to be enabled in a similar way in the future, it’s not today as there are some open issues related to it.

Regarding BATCH_VERSIONED_DATA, we’re not setting it today but I guess we could take this in consideration; I’d need to better understand what implications this would have on designing applications making use of optimistic lockinng.

In general, I prefer to not expose many of these but rather make sure we automatically set the best strategies; this might also lead to removing of some such properties from ORM down the road, and allow us to better test all permutations of these options.