LuciferYang opened a new pull request, #9899: URL: https://github.com/apache/paimon/pull/9899
### Purpose close #9898 When a data-evolution row-id-range group has no file that writes the query's projected columns, read-type pruning keeps one file as a row-count representative so the reader emits the right number of NULL-filled rows. The representative was `group.get(0)`, which can be a blob or vector-store file. Those files cover only a sub-range of the group's row ids, so the split silently emitted fewer rows than the group actually contains. This uses `retrieveAnchorFile` instead, which returns a full-range normal data file and never a blob or vector-store file (the same primitive the deletion-vector anchor path already relies on). The pruning core is extracted into a `@VisibleForTesting` static method so the representative choice can be pinned by a unit test with a blob file ordered first in the group. The filter-field logic added by #9872 is preserved: the instance method still folds in the fields referenced only by the filter and passes them to the static method, so the set of kept files is unchanged. ### Tests `DataEvolutionFileStoreScanTest#testReadTypePruningKeepsAnchorAsRowRepresentative` builds a group of a blob file covering rows 0-1 (ordered first) plus two full-range normal files covering rows 0-9, with a `readType` referencing a column no file writes. It asserts the representative is the full-range normal file. Against the old `group.get(0)` fallback the representative is the blob file, so the assertion fails. -- 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]
