yuqi1129 opened a new issue, #12153: URL: https://github.com/apache/gravitino/issues/12153
### Describe the subtask For catalogs that cannot store Gravitino's `StringIdentifier` in the external object (id-less catalogs such as JDBC/PostgreSQL schemas), a lost or soft-deleted store row is re-imported under a **brand-new** id: `TableOperationDispatcher.importTable`, in the `stringId == null` branch, calls `idGenerator.nextId()`. Any Gravitino-only relation keyed to the old id — owner, tag, policy, statistic — is then left dangling. This is a pre-existing issue (independent of the TreeLock work) and worth fixing on its own to make id-less imports idempotent. ### How to fix In the id-less branch of `importTable`, before minting a new id, look up an existing row for the same name **including soft-deleted rows** and reuse its id; only call `idGenerator.nextId()` when none is found. For id-ful catalogs (Hive/Iceberg) the id is already reused, so no change there. - New `*MetaService` query: get id by name including `deleted_at != 0`. - Bound: effective within the `STORE_DELETE_AFTER_TIME` window before `RelationalGarbageCollector` hard-deletes the tombstone. - Tests: crash / failed-delete then re-import keeps the same id; concurrent two-node import does not collide. ### Parent issue https://github.com/apache/gravitino/issues/10238 -- 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]
