morningman commented on PR #69723: URL: https://github.com/apache/doris/pull/69723#issuecomment-6545391448
@Gabriel39 a heads-up on overlap with two open PRs, so we can agree on the merge order. - **#69821** (V1 Iceberg reader: build missing equality-delete keys of legacy plans as full NULL columns, one commit, CI green, waiting for one approval). This PR deletes 4 of its 5 files (`be/src/format/table/equality_delete.cpp`, `iceberg_reader_mixin.h` and both test files), so merging both gives four modify/delete conflicts. If #69821 can go in first, this PR only needs to keep its deletions when it rebases. If this PR lands first, I will close #69821. In that case, could you check that V2 handles the same input: a plan from an FE older than 4.1.4, which sends no `iceberg_scan_semantics_version`, reading a data file that lacks one of the equality-delete keys (for example a composite non-byte key, or a nested key matched by name mapping)? On V1 this fails with NOT_IMPLEMENTED or aborts; the V2 tests I looked at all set the v2 semantics version. - **#69581** (Lance reader on FileScannerV2). Merging both conflicts in 8 files: `file_scan_operator.cpp`, `materialization_opertor.cpp`, `rowid_fetcher.cpp`, `file_scanner_v2.cpp`, `rowid_fetcher_test.cpp` and `file_scanner_v2_test.cpp`, plus `orc_read_lines.cpp` and `parquet_read_lines.cpp`, which this PR deletes and #69581 changes. Whichever PR merges second rebases. When do you expect this one to land? That helps me decide whether to rebase #69581 onto it ahead of time. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
