lasdf1234 opened a new issue, #14611:
URL: https://github.com/apache/gravitino/issues/14611
### Version
main branch
### Describe what's wrong
Tag-value precedence works only within the same tag. Policies of the same
`policyType` that arrive through different tags accumulate on an object.
Example: a catalog tagged `maint=standard` and table `t1` tagged
`maint=strict` resolve correctly (t1 gets only the strict compaction policy).
When `t1` is also tagged `hot`, and `hot` carries another compaction policy,
both compaction policies are in effect on `t1`: `GET
.../objects/table/.../policies?details=true` returns both.
`docs/migration-guide.md` currently leaves per-type resolution to consumers.
Without platform-level precedence, consumers such as TMS can turn every
effective policy into its own strategy and apply conflicting thresholds for the
same built-in maintenance type on one object.
### Requirement
For each `policyType`, an object has at most one **effective** policy,
resolved in three levels:
1. a policy attached directly to the object (hidden-tag / direct-binding
path),
2. a policy arriving through a tag assigned to the object itself,
3. a policy inherited from an ancestor's tags, nearest ancestor first.
A nearer level overrides a farther one. Within one level, associating a
second policy of the same type is rejected with an error naming the object and
both policies.
On table `t1`:
- tag `maint=strict` (compaction) is accepted and overrides the catalog's
`maint=standard`;
- tag `hot` (compaction) is rejected, because a table tag already provides
compaction;
- direct attachment of another compaction policy is accepted and overrides
all tags;
- a second direct compaction policy is rejected.
Conflict checks run at both entry points: assigning a tag to an object, and
linking a policy to a tag already assigned to objects (the error lists the
conflicting objects). A tag that carries no policy of the conflicting type is
not affected. An overridden policy stays associated and is shown as overridden
in the object's policy list; removing the overriding policy brings it back into
effect.
For catalog / schema / table objects, this means each object ends up with at
most one effective policy per `policyType` (for example at most one compaction,
one orphan-file removal, one manifest rewrite, and one snapshot expiration).
Different types may coexist.
### How to reproduce
1. Create tag `maint` with allowed values `standard` and `strict`; link
`maint=standard` to one compaction policy and `maint=strict` to a second.
2. Assign `maint=standard` to a catalog and `maint=strict` to a table under
that catalog.
3. Create tag `hot`, link it with `ALL_VALUES` to a third compaction policy,
assign it to the table.
4. `GET
/api/metalakes/{metalake}/objects/table/{fullName}/policies?details=true`
returns two compaction policies.
### Additional context
Enterprise tracking:
https://github.com/datastrato/gravitino-enterprise/issues/2882
Related: direct policy binding through hidden tags (enterprise #2881).
`docs/migration-guide.md` currently says consumers must decide which policy
types they can use; this change would move same-type precedence into
Gravitino's object policy resolution and association validation.
--
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]
