Branch: refs/heads/main Home: https://github.com/hibernate/hibernate-search Commit: 341c53933fb55d059f4e4018035affc302f17c6b https://github.com/hibernate/hibernate-search/commit/341c53933fb55d059f4e... Author: Yoann Rodière <yoann(a)hibernate.org&gt; Date: 2023-10-03 (Tue, 03 Oct 2023) Changed paths: M integrationtest/mapper/orm-jakarta-batch/src/test/java/org/hibernate/search/integrationtest/jakarta/batch/component/HibernateSearchPartitionMapperComponentIT.java M mapper/orm-jakarta-batch/core/src/main/java/org/hibernate/search/jakarta/batch/core/massindexing/step/impl/HibernateSearchPartitionMapper.java Log Message: ----------- HSEARCH-4986 Avoid calls to `scroll` on exhausted scrolls in Jakarta Batch job Commit: cf4923f4312771e3abbf74952240b72adbd919c6 https://github.com/hibernate/hibernate-search/commit/cf4923f4312771e3abbf... Author: Yoann Rodière <yoann(a)hibernate.org&gt; Date: 2023-10-03 (Tue, 03 Oct 2023) Changed paths: M integrationtest/mapper/orm-jakarta-batch/src/test/java/org/hibernate/search/integrationtest/jakarta/batch/component/HibernateSearchPartitionMapperComponentIT.java M mapper/orm-jakarta-batch/core/src/main/java/org/hibernate/search/jakarta/batch/core/massindexing/step/impl/HibernateSearchPartitionMapper.java M mapper/orm-jakarta-batch/core/src/main/resources/META-INF/batch-jobs/hibernate-search-mass-indexing.xml Log Message: ----------- HSEARCH-4986 Avoid scrolls when mapping Jakarta Batch partitions Support for scrollable resultsets is very inconsistent from one JDBC driver to the next: * Only H2 supports calling ResultSet.relative(<positive value>) on forward-only scrolls, others require using either ResultSet.TYPE_SCROLL_SENSITIVE or ResultSet.TYPE_SCROLL_INSENSITIVE. * Derby (and maybe others) doesn't support ResultSet.TYPE_SCROLL_SENSITIVE. * DB2 doesn't support ResultSet.TYPE_SCROLL_SENSITIVE together with a max number of rows, it will give DB2 SQL Error: SQLCODE=-243. It requires ResultSet.TYPE_SCROLL_INSENSITIVE. * Some drivers apparently don't support ResultSet.TYPE_SCROLL_INSENSITIVE at all. * Some drivers apparently fetch rows between the current position and the next (or even more!) even when using ResultSet.relative(<positive value>), which could be disastrous performance-wise in our case. * Etc. So the easiest, most practical solution is to just run one query per partition to find its upper bound. We don't have this problem for other scrolls because those just use .next(), while works fine with ResultSet.TYPE_FORWARD_ONLY on all databases. Commit: cafccd8bb183d1d94ca3aa6ed6bbc6630f20e2a6 https://github.com/hibernate/hibernate-search/commit/cafccd8bb183d1d94ca3... Author: Yoann Rodière <yoann(a)hibernate.org&gt; Date: 2023-10-03 (Tue, 03 Oct 2023) Changed paths: M mapper/orm-jakarta-batch/core/src/main/java/org/hibernate/search/jakarta/batch/core/massindexing/step/impl/HibernateSearchPartitionMapper.java Log Message: ----------- HSEARCH-4986 Fix verbose and unformatted log for Jakarta Batch partitions Compare: https://github.com/hibernate/hibernate-search/compare/ff30ef49ae60...cafc...