yuqi1129 opened a new pull request, #13503: URL: https://github.com/apache/gravitino/pull/13503
### What changes were proposed in this pull request? - `TableMetaService.insertTable(overwrite = true)`: before the upsert, in the same schema-locked transaction, delete a row that holds the table's name under a different id, together with its dependents (columns, version, tag/owner/securable relations, statistics). It reuses the drop path's CAS (`deleteTableWithVersion`) and cleanup (`deleteTableDependents`). An overwrite with the same id, e.g. a re-import after an out-of-band rename, is unchanged. - `TableOperationDispatcher.importTable`: overwrite only when the id comes from the table's properties. A generated id identifies nothing, so a concurrent import of the same table keeps its row: the plain insert conflicts and `loadTable` reloads it, as before. ### Why are the changes needed? A table dropped outside Gravitino leaves its registration in the store. Creating a table with the same name again goes through `store.put(entity, true)` with a new id: - On MySQL/H2, `ON DUPLICATE KEY UPDATE` matches the `(schema_id, table_name, deleted_at)` unique key and keeps the stale `table_id`, so the new table inherits the old table's tags, owner, privileges and statistics. - On PostgreSQL, `ON CONFLICT (table_id)` doesn't cover the name key, so the insert fails and the store write is lost. Without the `importTable` change, the stale-row replacement would let the last of two concurrent imports of a table without a stored id delete the first import's row. Schema, topic and view creates follow the same `put(overwrite)` pattern and are tracked separately in #13303. Privileges already pushed to name-based authorization plugins (e.g. Ranger) for the old table are not touched, as with any out-of-band drop. Fix: #13502 ### Does this PR introduce _any_ user-facing change? Yes. A table recreated under the name of a stale registration now gets a new identity and no longer inherits the old table's tags, owner, privileges or statistics. No API or configuration changes. ### How was this patch tested? - `TestTableMetaService.testOverwriteWithDifferentIdRetiresStaleTable`: fails without the fix on all three backends (H2/MySQL keep the stale id, PostgreSQL throws `EntityAlreadyExistsException`) and passes with it. It replaces `testNaturalKeyOverwriteUsesPersistedTableId`, which asserted the old id-preserving behavior. - `TestTableOperationDispatcher.testImportWithoutStoredIdDoesNotOverwriteConcurrentImport`: an import with a generated id writes without overwrite. - Ran `TestTableMetaService` locally on H2, MySQL and PostgreSQL, and `TestTableOperationDispatcher` on H2. The full `:core` suite is left to CI. -- 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]
