alitrack commented on PR #819: URL: https://github.com/apache/hudi-rs/pull/819#issuecomment-6242051627
Status note from the consumer side (duckdb-hudi, building index decoders on this API): three findings from validating against the repo's own fixtures that may help the review. 1. **Per-partition reads do not hit the gap.** The v2 reader decodes HFile→Arrow internally, so (272 rows) and (48 rows) on come back as clean batches even though the MDT union-of-records schema uses named-type references. This PR is self-contained — no avro-Ref fix needed first. 2. **Point lookups with work end-to-end on a sharded partition.** The record-index partition stores the **bare record key** (e.g. , not SHA-1 hashed), so routing () and the HFile key match line up: a lookup for returns exactly one row (opening 1 of the 10 shards); a lookup for a non-existent key returns an empty batch, not an error. This is what the "matched as stored" doc comment promises, now measured. 3. **Caveat for API callers (pre-existing kernel behaviour, not introduced by this PR):** file groups that are log-only with zero non-tombstone log records fail with (). That is what a full read of the partition hits on the V8 trips table, and of the partitions on the v9 fixture. Worth a note on the public method, or special-casing the all-tombstone log case in the merge-schema lookup. The sample tables in this repo reproduce all of the above without any external data. Would be great to get a reviewer on this — it unblocks the DuckDB extension's record-index / bloom / point-lookup surface. -- 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]
