linliu-code opened a new pull request, #658: URL: https://github.com/apache/hudi-rs/pull/658
**Stacked on #639–#657** — their commits appear here until they merge. **Review only the last commit.** ## Why `FileGroupReader` is doing two unrelated jobs: | | Base files | Log blocks | Read shape | |---|---|---|---| | regular table | parquet / lance | Avro / parquet | scan + merge by key | | **metadata table** | **HFile** | **HFile** | lookup by key, merged by `FilesPartitionMerger` | They share a struct because they share the *file slice* shape, not because they share a read. ## What The metadata read moves to `metadata::table::reader`, next to the module that calls it, taking its tests and fixture constants along. 83 lines out of `FileGroupReader`. `is_metadata_table()` **stays** — it is public API (surfaced as `HudiFileGroupReader.is_metadata_table` in the Python binding), and a caller choosing a read path has to be able to ask the question. The instant-range helper is duplicated rather than shared, so neither reader compiles against the other. Fifteen lines, and both sides have tests. The visible result is that the HFile imports are gone from the regular reader. ## Why now It is a prerequisite for retiring the legacy regular-table path once the ported reader is enabled. `reader_v2` has **no HFile support** — the source it came from removed the metadata table — so that path stays on the current reader permanently. With the two separated, that eventual step is a deletion rather than a dissection. It is also justifiable on its own: these are two jobs in one struct. No behavior change. Full workspace suite green (1105 lib + 79 table-read); build warning-free. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
