You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Vyom Mani Tiwari (Jira)" <ji...@apache.org> on 2026/10/21 08:28:00 UTC
[jira] [Created] (RANGER-5851) Admin: persist constraintDefs of service definitions
Vyom Mani Tiwari created RANGER-5851:
----------------------------------------
Summary: Admin: persist constraintDefs of service definitions
Key: RANGER-5851
URL: https://issues.apache.org/jira/browse/RANGER-5851
Project: Ranger
Issue Type: New Feature
Components: admin
Reporter: Vyom Mani Tiwari
Assignee: Vyom Mani Tiwari
RANGER-5838 added {{constraintDefs}} to {{{}RangerServiceDef{}}}. Ranger Admin doesn’t store them yet, so they’re dropped when a service def is created or updated. This sub-task adds that storage.
_Scope_
* Store {{constraintDefs}} on service def create and update, and return them on get, through REST and {{ServiceDBStore}} / {{{}RangerServiceDefServiceBase{}}}.
* Validate constraintDefs in {{{}RangerServiceDefValidator{}}}:
** names and itemIds are unique and not empty;
** {{resources}} and {{accessTypes}} refer to resources and access types that exist in the service def;
** each {{resources}} list forms a valid chain that includes its ancestors;
** parameter names are unique, and parameter {{type}} values are supported.
* Include constraintDefs in service-def export/import and in the service def sent to plugins.
* Updates: decide what happens to constraint policies that reference a constraintDef that is removed or renamed. Proposal: reject the update while policies reference it, as is done for access types in use.
_Storage (decision needed)_
Today each service-def section has its own tables: {{{}x_access_type_def{}}}, {{{}x_resource_def{}}}, {{{}x_datamask_type_def{}}}, …. Options:
# A new table, {{x_constraint_def}} (name, label, description, resources, accessTypes, parameters as JSON, rb keys, item_id, def_id), with DB patches for MySQL, Postgres, Oracle and SQL Server. This is consistent with the other sections.
# A JSON column on {{x_service_def}} holding the whole {{constraintDefs}} list. This needs a smaller schema change.
Proposal: option 1 for the table, with {{parameters}} stored as JSON inside it, to avoid a second child table.
_Testing:_ unit tests for validation; service-store tests for create, update, get and delete round-trips; and an upgrade-patch test on each DB flavor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)