nevzheng opened a new issue, #12220: URL: https://github.com/apache/gravitino/issues/12220
### Describe the proposal This is a storage-focused child epic of #12219. Add the relational metadata foundation required to retain, discover, restore, and eventually purge soft-deleted entities. The initial implementation supports tables, while the core deletion record should permit additional entity types in the future. The storage model should provide: - An `entity_deletion` lifecycle record identified by an opaque, immutable `deletion_id`. - The original entity identity and version, parent identity, name and namespace snapshots, lifecycle state, optimistic revision, deletion time, retention deadline, actor, request correlation, cleanup status, and future purge-job association. - A nullable `deletion_id` pointer on `table_meta` and relevant table-owned metadata rows. - An `active_name_key` that uniquely reserves the canonical table name while a deletion remains active. - Append-only lifecycle events in `entity_deletion_audit`. - Terminal deletion and audit records that can survive final removal of the original metadata row. A table deletion must be recorded in one relational transaction. The transaction creates the deletion action, marks the exact table generation and its related metadata rows with the same `deletion_id`, reserves the canonical name, and records the lifecycle event. Restoration must address the deletion action by `deletion_id` and reactivate only the original table and related rows stamped with that deletion generation. It must not restore an object by name alone. Concurrent create, delete, and restore operations should use exact predicates, optimistic revisions, and transaction-scoped row-level coordination. The implementation must not introduce table-wide database locks. The storage changes must support fresh installations and upgrades on H2, MySQL, and PostgreSQL, with tests for transaction atomicity, deletion-generation isolation, name reservation, exact restoration, concurrent changes, and terminal-record retention. This epic establishes storage capabilities only. Public APIs, Iceberg physical cleanup, purge scheduling, worker execution, and per-file cleanup progress are covered by separate epics. ### Task list - [ ] Define implementation subtasks and reviewable PR boundaries — pending -- 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]
