jackylee-ch commented on code in PR #1042:
URL: https://github.com/apache/paimon-rust/pull/1042#discussion_r4343698905
##########
crates/paimon/src/table/table_read.rs:
##########
@@ -466,10 +466,21 @@ impl<'a> PaimonTableRead<'a> {
}
}
}
- // Delta / Changelog rows are read as-is from planned files (no
full-table
- // merge against historical base versions).
+ // Delta / Changelog rows are read as-is from planned files, without a
merge
+ // against historical base versions. Files are still decoded as an
ordinary
+ // read decodes them: primary-key BLOB descriptors resolve to
payloads, and
+ // data-evolution files in a split that hold column slices of the same
rows
+ // merge by row id.
let data_splits = self.matching_splits(&data_splits)?;
- self.new_data_file_reader()?.read(&data_splits)
+ let core_options = self.table.schema().core_options();
+ if !self.table.schema().primary_keys().is_empty() {
+ return self
+ .resolving_primary_key_blobs(&core_options, |read|
read.read_raw(&data_splits));
+ }
+ if core_options.data_evolution_enabled() {
+ return self.read_with_evolution(&data_splits, &core_options);
Review Comment:
Fixed in f8016e1: for a split of change events (`DataSplit::is_streaming`),
the merge reader reads a field no file of the group wrote as NULL, NOT NULL and
nested ones included; snapshot reads keep the check. This covers auto/delta and
plain/audit here and core's other change-event reads (`plan_combined_delta` +
`to_arrow`, `incremental-between-timestamp`, stream follow-ups). Java rejects
this case; the SQL guide says so. A merge group of only `.blob`/`.vector.`
files (e.g. a range that only rewrites a VECTOR column) still fails with
"requires at least one normal data file", as on main.
--
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]
