JunRuiLee commented on code in PR #752:
URL: https://github.com/apache/paimon-rust/pull/752#discussion_r3894253309
##########
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 =>
Review Comment:
Fixed in 3df9e15. `TableSchema::copy_with_options` now pins the option to
the stored value, and drops the override entirely when nothing is stored so the
default stands — the shape it already uses for `type`. Java rejects such an
override outright (`AbstractFileStoreTable.checkImmutability`); this copy is
infallible, so pinning is the closest equivalent.
Tests: a copied-with-`false` table still writes its hash index into the
bucket directory, a read through `Table::copy_with_options` still reports the
stored layout, and the pin in both directions. `copy_with_replaced_options` and
`Table::new` stay unpinned — they take options wholesale rather than as an
override, as `type` has always been.
One correction: a writer and its committer come from the same
`WriteBuilder`, so abort resolves the layout the write used. The damage that
needs no such crossing is the successful commit itself.
--
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]
