yuqi1129 commented on issue #12153: URL: https://github.com/apache/gravitino/issues/12153#issuecomment-5044248472
Closing as **not planned** — this approach is unsound and cannot be fixed for id-less catalogs. The idea was: on re-import, reuse a matching soft-deleted (tombstoned) store row's id instead of minting a new one, to keep the id stable and avoid dangling relations. On analysis it does not hold: - A tombstone is produced by `store.delete`, which in `dropTable` runs **after** the external drop. So a same-named tombstone means the external object was already gone at drop time; a same-named external object that exists **now** was created afterwards — a *different* logical table that merely reuses the name. Reusing the old id would resurrect the old table's owner/tag/policy/statistic relations onto that new object — a stale-authorization leak, worse than a fresh id. - The only case where reuse would be correct (the very same table, its store row lost transiently) leaves **no** tombstone: it comes from a crash between external-create and `store.put`, where the row was never written and no relations exist yet. So a name-keyed lookup wins nothing and loses correctness exactly when it fires. Fundamentally, identity requires an id carried by the object; when the object cannot carry one (id-less catalogs), name is ambiguous across delete/recreate and no algorithm resolves it. This is now documented as an inherent limitation in the design doc. The actionable part of this hazard — cleaning up relations orphaned by out-of-band store-row loss — is handled by #12154, which removes relations pointing at ids with no live entity and does **not** need to resolve identity. The normal `dropTable` path already cascades relations away in one transaction, so drop-then-recreate is clean under a fresh id. -- 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]
