JunRuiLee commented on code in PR #752:
URL: https://github.com/apache/paimon-rust/pull/752#discussion_r3894254739
##########
crates/paimon/src/catalog/filesystem.rs:
##########
@@ -575,6 +587,18 @@ fn reject_table_type_changes(
message: format!("removing '{TABLE_TYPE_OPTION}' is not
supported"),
});
}
+ crate::spec::SchemaChange::SetOption { key, .. }
+ | crate::spec::SchemaChange::RemoveOption { key }
+ if key == INDEX_FILE_IN_DATA_FILE_DIR_OPTION =>
+ {
+ return Err(Error::Unsupported {
+ message: format!(
+ "changing '{INDEX_FILE_IN_DATA_FILE_DIR_OPTION}' is
not supported: \
Review Comment:
Fixed in 3df9e15. The guard now takes `has_snapshots` and rejects only an
actual change once snapshots exist; `RemoveOption` only with snapshots, set or
not. `type` stays unconditional, as in Java — a format table holds data without
writing a snapshot. `alter_table` resolves the flag only when a change touches
the option.
One case that looks like a no-op and is not: `false` where the option was
never stored. Java compares the stored value and normalizes only `type`,
`primary-key` and `partition`, so it counts as a change and is rejected once
snapshots exist. Tested, along with the four you listed.
Gating on snapshots leaves a window, now in the guard's docs: a writer that
started before the alter still holds the old layout, and a commit records its
schema id without checking whether the latest schema moved. Java's cached lazy
check has the same one; closing it belongs on the commit path.
--
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]
