JingsongLi commented on code in PR #942:
URL: https://github.com/apache/paimon-rust/pull/942#discussion_r4177418651
##########
crates/integrations/datafusion/src/procedures.rs:
##########
@@ -453,6 +455,23 @@ async fn proc_create_tag(
ok_result(ctx)
}
+async fn proc_rename_branch(
+ ctx: &SessionContext,
+ catalog: &Arc<dyn Catalog>,
+ catalog_name: &str,
+ args: &HashMap<String, String>,
+) -> DFResult<DataFrame> {
+ let table = get_table(catalog, catalog_name, args).await?;
+ let from_branch = require_arg(args, "from_branch")?;
+ let to_branch = require_arg(args, "to_branch")?;
+
+ let bm = BranchManager::new(table.file_io().clone(),
table.location().to_string());
Review Comment:
[P2] Reject REST rename before moving catalog-managed branch files
get_table also accepts RESTCatalog tables, but this constructs a filesystem
BranchManager regardless of the table RESTEnv. A real HTTP/Parquet probe first
reads t1$branch_b1 through REST (authoritative snapshot 7), then CALL
rest.sys.rename_branch(..., from_branch => b1, to_branch => b2) returns success
and moves the physical directory without any catalog mutation. Fresh SQL reads
of b1 fail with Branch b1 does not exist; b2 is rejected by the unchanged
catalog with TableNotExist. Java selects CatalogBranchManager for this
environment, and RESTCatalog.renameBranch explicitly throws
UnsupportedOperationException before moving files. Preserve that contract by
refusing REST rename until a catalog-aware operation exists; a temporary early
REST guard makes the same preservation probe pass without breaking native
rename.
--
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]
