LuciferYang opened a new pull request, #9513:
URL: https://github.com/apache/paimon/pull/9513
### Purpose
close #9512
`InternalRowPartitionComputer`'s constructor sized `partitionFieldGetters`
and `partitionCastExecutors` by the number of partition columns, then stored
into them at the partition column's position in the full row schema.
`generatePartValues` reads all three of `partitionFieldGetters[i]`,
`partitionCastExecutors[i]` and `partitionColumns[i]` with one loop variable
over the partition columns, so the array bound and the index expression have to
agree, and they only agree when the partition columns are a prefix of the row
type in row order.
Each getter is now stored at its partition-column position, while the type
and the field position it reads still come from the row schema.
Nothing in the constructor's signature requires the partition columns to be
a row prefix, but every current caller passes a row type already projected to
the partition columns in `partitionKeys` order
(`TableSchema.logicalPartitionType()`, `store().partitionType()`,
`rowType().project(partitionKeys())`, `TypeUtils.project(rowType,
partitionKeys)`). `indexOf` therefore always returns the loop position, old and
new code produce identical arrays at every call site, and the bug is latent
rather than something a deployment hits today. It fires as soon as a caller
hands over the full row type: either `ArrayIndexOutOfBoundsException`, or, when
the row positions happen to be in range, a partition spec in which every column
name carries another column's value with no error raised.
### Tests
Two cases in `InternalRowPartitionComputerTest`, one per failure mode.
- `testPartitionColumnNotAtRowPrefix`: row type `id, dt, region, extra` with
partition columns `{region, dt}`. `region` sits at row position 2, out of range
for a two-element array. Fails on the old code with
`ArrayIndexOutOfBoundsException: 2`.
- `testPartitionColumnsReorderedWithinRowPrefix`: row type `id INT, dt
STRING, region STRING` with partition columns `{dt, id}`. Both row positions
are in range, so the old code does not throw; it returns `{dt=1, id=20240731}`
instead of `{dt=20240731, id=1}`. Mixed types make the crossed values visible
rather than symmetric.
Both assert with `containsExactly(entry(...), entry(...))`, which pins the
iteration order of the returned `LinkedHashMap` as well as the pairing, since
partition paths and partition specs consume that order.
Verified red before the change (`ArrayIndexOutOfBoundsException: 2` and
crossed values respectively), and the pre-existing `testPartitionToString`
stays green.
`mvn -pl paimon-common test` on JDK 8: 12467 tests, 0 failures, 0 errors.
checkstyle, spotless, enforcer and rat run clean.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
