<query> <filter> <ref> <path>assignment/targetRef</path> <value relation="default"></value> <target> <equal> <path>name</path> <value>a-test-4</value> </equal> </target> </ref> </filter> </query>
Query API: Proposed Features for 4.6
|This is feature proposal for midPoint 4.6, it intention is to discuss proposed solutions and resulting implementation may differ.|
Match on reference and it’s target properties at same time
Filters currently can match reference itself based on it’s parameters such
type or we can use dereferencing paths (paths containing
to match properties on referenced objects, but we can not match on both.
Adding option for
target inside ref filter would allow us to write filters
which targets both reference itself and target.
In Axiom Query this could be:
assignment/targetRef matches ( relation = "default" and @ matches ( name = 'a-test-4' ) )
Also alternative with
target is permitted.
assignment/targetRef matches ( relation = "default" and target matches ( name = 'a-test-4' ) )
target would allow any valid filter to be executed. Most common use would be
probably use with
type filter (to allow matching on target type specific properties),
but other filters could be used.
In short ref filter without target filter specified will behave as before, once target filter it is specified it will work as join filter.
Open Question: target exists filter?
Interestingly this allows to construct filter like:
assignment/targetRef matches (target not exists)
Note that similar filter could be created using path
assignment/target/@ not exists
Should this filter match any assignment, which target does not exist?
JOIN filter: referencedBy
- MID-4343 Seach: join
Support searches that "join" two object types. For example allow to search all roles, that are assigned to particular user.
From description it seems, that we want to find target based on criteria on object which references it - this inverts ref filter relation.
In order for such filter to work user needs to specify following:
Reference which is used for reverse search, this could be expressed as
Criteria which referencing object must match.
query: type: RoleType filter: referencedBy: type: UserType path: assignment/targetRef filter: equal: path: archetypeRef/@/name value "System User"
. referencedBy ( @type = UserType and @path = assignment/targetRef and archetypeRef/@/name = "System User" )
. referencedBy ( . type = UserType and @path = assignment/targetRef and archetypeRef/@/name = "System User" )
This may looks cumbersome, but
targetfilter properties are neccessary.
pathspecifies which reference is used for search.
targetprovides additional properties (could be empty to match all).
typeis neccessary to provide schema for parsing
filterfilter, also specify which data should be searched.
Optional: Distinguish between object properties and parent container properties
Current proposed form of
referencedBy assumes nested filter starts at object level.
This does not allows to write directly filter such as referencedBy and match also on assignment properties and object properties at same time. This could be possible if we allow
referencedBy/@type to be any type.
System Userarchetype and their assignment has
.referencedBy ( @type = AssignmentType and @path = targetRef and extension/secret exists and . ownedBy ( @type = UserType and archetypeRef/@/name = "System User" ) )
If we allow for parent paths and absolute paths, we can say in specification parent is owning element, then this filter could be written also as:
.referencedBy ( @type = UserType and @path = assignment/targetRef and ../extension/secret exists and /archetypeRef/@/name = "System User" )
ownedBy filter allows for matching indexed containers based on properties of their parent (owning object or container).
The syntax is similar to
ownedBy filter can only be applied on self path (
The properties of ownedBy filter are:
(Required) Type of parent / owner
(Optional) name / location of container inside parent
(Optional) filter, to which parent needs to conform, filter is explicit element in XML/YAML/JSON. In Axiom any filter which is not special property of
ownedByis automaticly nested in filter.
Example: Find all assignments only using searchContainers
ownedBy: type: AssignmentHolderType path: assignment
. ownedBy ( @type = AssignmentHolderType and @path = assignment)
Find all User assignments which has
secret extension property set to
users have archetype
and: - equal: path: extension/secret value: true - ownedBy: type: UserType path: assignment filter: equal: path: archetypeRef/@/name = "System User"
extension/secret = true and . ownedBy ( @type = UserType and @path = assignment and archetypeRef/@/name = "system User" )
Default Matching Rule / matching rules upgrade
we already have schema annotation
a:matchingRule, which allows to specify matching rule for property, currently this is used in provisioning for normalization of values.
We can extend support of this to Query implementations, that implementation will get default
matchingRule from property definition (which is defined by a:matchingRule), or we could define new property to not encroach on current use of
This solution would require:
*FilterImplclasses - eg.
definition.getMatchingRuleif matching rule is not defined in xml/axiom.
changes to schema XSD - items, where matching rules should be applied, should be annotated using
Additionally we should explore allowing specificiation of default
matchingRule on simple type definitions to
facilitate future use-cases, where this behaviour should be specified by value type (e.g introduction of types such as LdapDN, UUID).
The algorithm for selection of matching rule for search would be prefer most local definition, eg:
If filter specifies matching rule explicitly use it
If property definition specifies matching rule use it
If type definition (if supported) specifies matching rule use it
Use implementation specific matching rule (eg. default in database)
This filter allows matching left value against set of right values and returns true if any of left values is contained in right values (difference to equals is if right side is list, any value match returns true).