I just implemented the following strategies:
- if hibernate.query.in_clause_parameter_padding is enabled, a modified version of the legacy “coin change algorithm” approach is used - the modification is to use padding within each partition - SingleIdEntityPartitionedBatchLoader
- Otherwise, generally, a “static SQL” approach is used where we use a single SQL with batch-size number of parameters, with null padding for “empty slots” - SingleIdEntityPaddedBatchLoader
- Also implemented a dynamic approach where we create SQL on the fly each time for the specific number of ids.
Christian Beikov also suggested possibly using an array parameter which I also like. I think we should limit the options here a bit though. Does anyone see the benefit of the dynamic approach? To me, “static SQL” and array-parameter would be enough; maybe with a fallback to partitioned if the “static SQL” batch-size exceeds a certain limit? |
