jiangxt2 opened a new issue, #12761: URL: https://github.com/apache/gravitino/issues/12761
### Version main branch ### Describe what's wrong The ClickHouse catalog does not propagate a table rename across the configured ClickHouse cluster. Tables created through Gravitino with `on-cluster=true` contain trusted cluster metadata in their comments, and CREATE, ALTER, and DROP use that metadata to generate `ON CLUSTER` DDL. However, table rename delegates to the common JDBC implementation, which generates a local `RENAME TABLE old_name TO new_name` statement without `ON CLUSTER`. The operation succeeds on the ClickHouse node used by the JDBC connection but leaves the old table name on the other nodes. This silently splits the cluster metadata and can cause later Gravitino ALTER or DROP operations to fail or behave inconsistently. Expected behavior: a table with valid Gravitino cluster metadata should be renamed on every node, while local tables and unmarked external tables should retain the existing local rename behavior. ### Error message and/or stacktrace No exception is returned. The operation reports success even though the cluster nodes have different table names. The generated statement is equivalent to: ```sql RENAME TABLE clustered_old TO clustered_new ``` After executing it through the connection node: - the connection node contains `clustered_new` and not `clustered_old`; - another cluster node contains `clustered_old` and not `clustered_new`. ### How to reproduce 1. Use Gravitino from the main branch with a ClickHouse 25.3.2.39 cluster containing at least two nodes. 2. Configure a Gravitino JDBC ClickHouse catalog for one cluster node. 3. Create a table through Gravitino with `on-cluster=true` and a valid `cluster-name`. 4. Rename the table through `TableCatalog.alterTable(..., TableChange.rename(...))`. 5. Query `system.tables` for the old and new names on every ClickHouse node. 6. Observe that only the JDBC connection node has the new name; the other cluster nodes still have the old name. ### Additional context ClickHouse supports `RENAME TABLE old_name TO new_name ON CLUSTER cluster_name`. The propagation decision should use the cluster marker that Gravitino embeds in the stored table comment; it should not infer cluster ownership from similarly named tables on other nodes. The renamed table should retain its Gravitino identifier and cluster marker. -- 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]
