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)