JeonDaehong commented on code in PR #3145:
URL: https://github.com/apache/iceberg-rust/pull/3145#discussion_r4195070583
##########
crates/iceberg/src/arrow/caching_delete_file_loader.rs:
##########
@@ -334,10 +334,9 @@ impl CachingDeleteFileLoader {
/// Validates a deletion-vector task and returns what the read needs as
typed values:
/// `(start, len, referenced data file path, expected cardinality)`.
///
- /// The spec requires `referenced_data_file`, `content_offset` and
`content_size_in_bytes` on
- /// a deletion vector, and a deletion vector is always built from a
manifest entry, so it
- /// always carries `record_count`. A missing one is a manifest-entry
inconsistency rather
- /// than an I/O failure.
+ /// Builder-created tasks are validated up front, but deserialized scan
plans can bypass the
Review Comment:
Since FileScanTaskDeleteFile now deserializes through
FileScanTaskDeleteFileSerde -> build(), and the fields are private, I don't
think a task can reach this loader without going through validate() anymore.
So this comment ("deserialized scan plans can bypass the builder") looks out
of date after ea27138a9. Maybe reword it to say these checks only turn the
Options into values, or drop the duplicated checks?
--
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]
