| I've noticed this when logging progress to debug
HSEARCH-2758 Pull Request Sent . See this code in PartitionMapper:
private List<PartitionBound> buildPartitionUnitsFrom(ScrollableResults scroll, Class<?> clazz) {
List<PartitionBound> partitionUnits = new ArrayList<>();
int rowsPerPartition = SerializationUtil.parseIntegerParameter( ROWS_PER_PARTITION, serializedRowsPerPartition );
Object lowerID = null;
Object upperID = null;
while ( scroll.scroll( rowsPerPartition ) ) {
lowerID = upperID;
upperID = scroll.get( 0 );
partitionUnits.add( new PartitionBound( clazz, lowerID, upperID ) );
}
lowerID = upperID;
upperID = null;
partitionUnits.add( new PartitionBound( clazz, lowerID, upperID ) );
return partitionUnits;
}
The implementation of ScrollableResults we're using, org.hibernate.internal.ScrollableResultsImpl, starts positioned before the first element, so advancing 250 rows (for instance) will get us at the 250th element, which will be used as an upper bound for the first partition. The upper bound is excluded, thus the first partition will only include 249 elements, while the next partitions will include 250 elements. Calling scroll.next() before the loop should do the trick. |