jerryshao opened a new pull request, #13321:
URL: https://github.com/apache/gravitino/pull/13321
### What changes were proposed in this pull request?
On `branch-1.3`, deleting a tag or a policy now removes everything that
references it, in the same transaction as the tag or policy row.
- `TagMetaService.deleteTag` resolves the tag id first, then soft-deletes:
- the tag row;
- the tag's object relations (`tag_relation_meta`);
- policy relations where the tag is the metadata object;
- the tag's owner;
- its role securable objects.
- `PolicyMetaService.deletePolicy` resolves the policy id first, then
soft-deletes:
- the policy versions (now before the policy row);
- the policy row;
- the policy's object relations (`policy_relation_meta`);
- tag relations where the policy is the metadata object;
- its owner;
- its securable objects.
- The object relations are removed by id through two new mapper methods,
`softDeleteTagMetadataObjectRelsByTagId` and
`softDeletePolicyMetadataObjectRelsByPolicyId`. Each has a base (MySQL/H2) and
a PostgreSQL provider. This matches `main`.
- If the tag or policy row is already gone when it is deleted (renamed or
deleted concurrently after its id was read), the transaction rolls back and the
delete returns `false`. The cleanup therefore never touches the rows of an
entity that is still live under another name.
`main` already does this cleanup, but as part of the OCC work (#12781,
#12782), which can't be cherry-picked. This change ports it by hand.
### Why are the changes needed?
- **Deleting a tag:** the tag row was soft-deleted first. The relation
cleanup (`softDeleteTagMetadataObjectRelsByMetalakeAndTagName`) only matches
live tags (`tm.deleted_at = 0`), so it removed nothing. The owner and securable
objects were never removed.
- **Deleting a policy:**
- `softDeletePolicyMetadataObjectRelsByMetalakeAndPolicyName` was never
called.
- The version cleanup ran after the policy row was deleted and also
matches live policies only, so no version was ever retired.
- The owner and securable objects were never removed.
- `branch-1.3` has no orphan relation GC, so these rows stayed forever.
Fix: #13311
Part of #13303
### Does this PR introduce _any_ user-facing change?
No API or configuration change. Deleting a tag or policy now also removes
its assignments, its owner and the privileges granted on it.
A delete that races with a concurrent delete-and-recreate of the same name
on another server can still leave the new entity's relations behind, as before
this change. `main` handles that case with OCC.
### How was this patch tested?
- Added unit tests (H2 locally). Both fail without the fix and check the
relation rows directly:
- `TestTagMetaService.testDeleteTagCleansEveryDependentRelation`
- `TestPolicyMetaService.testDeletePolicyCleansEveryDependentRelation`
(also checks that every policy version is retired)
- `./gradlew :core:test -PskipITs` passes locally.
- The new SQL needs the MySQL and PostgreSQL backends in CI.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
