TheR1sing3un commented on code in PR #379:
URL: https://github.com/apache/paimon-rust/pull/379#discussion_r3400425404
##########
crates/paimon/src/table/write_builder.rs:
##########
@@ -80,6 +80,16 @@ impl<'a> WriteBuilder<'a> {
/// For primary-key tables, sequence numbers are lazily scanned per
partition
/// when the first writer for that partition is created.
pub fn new_write(&self) -> crate::Result<TableWrite> {
+ // A time-travelled table copy carries a historical schema; writing
+ // through it would silently produce data shaped like the old schema.
+ // Java avoids this structurally (write paths use
copyWithoutTimeTravel);
+ // here the same table copy can serve both reads and writes, so reject
+ // explicitly. Commit-only flows (new_commit) stay untouched.
+ if self.table.is_time_traveled() {
Review Comment:
Fixed in 05bdc13. `new_write` now rejects whenever the table options contain
a time-travel selector (`CoreOptions::try_time_travel_selector()` returning
`Some` or a conflicting-selector error), independent of whether the schema was
switched — matching the SQL-layer guard semantics. Covered by
`test_copy_with_time_travel_same_schema_still_rejects_write` (your exact
scenario: two snapshots without schema evolution) and a datafusion case
asserting `SET 'paimon.scan.version'='2'` + INSERT fails.
##########
crates/paimon/src/table/mod.rs:
##########
@@ -184,7 +199,54 @@ impl Table {
schema: self.schema.copy_with_options(extra),
schema_manager: self.schema_manager.clone(),
rest_env: self.rest_env.clone(),
+ time_traveled: self.time_traveled,
Review Comment:
Fixed in 05bdc13 by making the mismatched state fail loudly (your first
option). `copy_with_options` now only invalidates the resolved snapshot when
the merged options actually change the selector (`scan.version` /
`scan.timestamp-millis`); unrelated option merges keep the snapshot/schema pair
intact. If the selector is changed on a time-travelled copy,
`TableScan::resolve_snapshot` returns an error directing to
`copy_with_time_travel`, which re-resolves both the snapshot and the schema
(re-traveling an already-travelled copy is supported and tested). Re-resolving
inside `copy_with_options` itself wasn't viable since it is synchronous and
resolution needs IO. Covered by
`test_changing_selector_after_travel_fails_scan`.
--
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]
