Search before asking
Paimon version
master (1.5-SNAPSHOT)
Compute Engine
Any engine using the JDBC catalog.
Minimal reproduce step
Three independent failure-handling problems in JdbcCatalog.
-
Cascade dropDatabase leaks the database directory. Create a database and a table, then drop the database with cascade. The four JDBC row sets are removed, but the directory warehouse/<db>.db/ (schema and data) is left on the filesystem. FileSystemCatalog.dropDatabaseImpl deletes it; JdbcCatalog.dropDatabaseImpl did not. Recreating the same database and table then collides with the stale schema-0 (the schema is stored with putIfAbsent), so the table is not created cleanly.
-
alterDatabase on a missing database silently succeeds. Call alterDatabase("missing", setProperty, ignoreIfNotExists = false). No existence check is done: a property row is inserted and the call returns without error, where it should throw DatabaseNotExistException. Worse, databaseExists then reports the database as existing, materializing a phantom database that shows up in getDatabase and listDatabases.
-
createTable leaks a directory on a specific failure path. When a create fails after the schema has been committed to the filesystem but before the JDBC row is inserted, the catch block rethrows without removing the directory it just created.
What doesn't meet your expectations?
A failed or aborted catalog operation should not leak filesystem state, silently report success, or materialize a phantom database.
Anything else?
The create-table cleanup must be careful: a table can exist on the filesystem while being absent from the JDBC catalog (the state repairTable / repairCatalog recover). Cleanup on a failed create must remove only a directory that this call created, never a pre-existing one.
Are you willing to submit a PR?
Search before asking
Paimon version
master (1.5-SNAPSHOT)
Compute Engine
Any engine using the JDBC catalog.
Minimal reproduce step
Three independent failure-handling problems in
JdbcCatalog.Cascade
dropDatabaseleaks the database directory. Create a database and a table, then drop the database with cascade. The four JDBC row sets are removed, but the directorywarehouse/<db>.db/(schema and data) is left on the filesystem.FileSystemCatalog.dropDatabaseImpldeletes it;JdbcCatalog.dropDatabaseImpldid not. Recreating the same database and table then collides with the staleschema-0(the schema is stored with putIfAbsent), so the table is not created cleanly.alterDatabaseon a missing database silently succeeds. CallalterDatabase("missing", setProperty, ignoreIfNotExists = false). No existence check is done: a property row is inserted and the call returns without error, where it should throwDatabaseNotExistException. Worse,databaseExiststhen reports the database as existing, materializing a phantom database that shows up ingetDatabaseandlistDatabases.createTableleaks a directory on a specific failure path. When a create fails after the schema has been committed to the filesystem but before the JDBC row is inserted, the catch block rethrows without removing the directory it just created.What doesn't meet your expectations?
A failed or aborted catalog operation should not leak filesystem state, silently report success, or materialize a phantom database.
Anything else?
The create-table cleanup must be careful: a table can exist on the filesystem while being absent from the JDBC catalog (the state
repairTable/repairCatalogrecover). Cleanup on a failed create must remove only a directory that this call created, never a pre-existing one.Are you willing to submit a PR?