Processing mapping sets

Last modified 25 Oct 2021 16:44 +02:00

See Mapping for background information.

Evaluation of mapping sets converts source object into a set of item deltas to be applied on this (or other) object. It consists of evaluation of the mappings (probably chained because of mutual dependencies) and of consolidation of output triples into item deltas.

Compared with single mapping evaluation it provides the conversion of output triples into item deltas, applying settings for individual mappings, namely the strength (normal, strong, weak).

Mapping set evaluation

This is basically repeated evaluation of individual mapping, with the only exception: mapping chaining.

Mapping chaining

Individual mappings in mapping set can have mutual dependencies: target item of mapping A can be a source of mapping B. Such cases have two consequences:

A must be evaluated before B.
Before starting evaluation of B, we must create an intermediate version of sources for mapping B. Sources derived from original source object are no longer adequate. When determining updated sources, interim consolidation has to be run.

(This interim consolidation is currently implemented not very precisely. We need to analyze it in more depth eventually.)

Consolidation

Consolidation is a process of converting output triple map to item deltas, considering source object along with its pre-existing delta. Because this process is executed independently for each item in question, we can describe item consolidation that converts single output triple to an item delta, considering source item-delta-item. In some cases the actual value of item is not known: this can occur if we are consolidating values for resource object attribute, and we do not have full shadow for the object.

Item consolidation

Item consolidation goes strictly "by value". In each step we take one of values present in the delta set (from plus, minus, and zero sets) - let’s call it v₀ - and identify its presence in the delta set triples as well as in existing item. By "presence" we mean set of values equivalent with v₀ under specified value matcher or comparator (or IGNORE_METADATA comparison if none of these two is specified). ^[1]

The algorithm then goes like this (slightly simplified - assuming mapping selector is ALL and exclusiveStrong is false):

Let:

Symbol(s)	Meaning
P, M, Z	Sets of values in plus, minus, and zero sets, respectively. So P = { v₁^plus, v₂^plus, …, v_k^plus }, M = { v₁^minus, v₂^minus, …, v_l^minus }, Z = { v₁^zero, v₂^zero, …, v_m^zero }
P₀ ⊆ P, M₀ ⊆ M, Z₀ ⊆ Z	Sets of values-with-origins having values equivalent with v₀ in P, M, and Z, respectively. Because of value equivalence we can view these as simply origins or mappings. In the figure above they are depicted in pink. (In real algorithm implementation they are filtered using strength selector and construction validity check.)
addUnchanged	Consolidation parameter that tells that all unchanged (zero-set) values should be considered for "add" part of resulting item delta. It is typically set to true when the whole target object is being added. (And also for attribute reconciliation when apriori delta is REPLACE.)
addUnchangedValuesExceptForNormalMappings	Consolidation parameter that tells that some of the unchanged values should be considered for "add" part of resulting item delta. In particular, all values backed by strong, weak, and sourceless normal mappings. It is set for object template evaluation for focus or personas and assigned focus mappings evaluation. It may be renamed/changed in the future.
existingItemKnown	Consolidation parameter that tells that we know the existing item. It is false for resource object mappings that operate on non-full shadows.
v_ex	Presence of v₀ in existing item. (May be null if v₀ is not present there or if existing item is not known.)

Symbol(s)

Meaning

P, M, Z

Sets of values in plus, minus, and zero sets, respectively. So P = { v₁^plus, v₂^plus, …, v_k^plus }, M = { v₁^minus, v₂^minus, …, v_l^minus }, Z = { v₁^zero, v₂^zero, …, v_m^zero }

P₀ ⊆ P, M₀ ⊆ M, Z₀ ⊆ Z

Sets of values-with-origins having values equivalent with v₀ in P, M, and Z, respectively. Because of value equivalence we can view these as simply origins or mappings. In the figure above they are depicted in pink. (In real algorithm implementation they are filtered using strength selector and construction validity check.)

addUnchanged

Consolidation parameter that tells that all unchanged (zero-set) values should be considered for "add" part of resulting item delta. It is typically set to true when the whole target object is being added. (And also for attribute reconciliation when apriori delta is REPLACE.)

addUnchangedValuesExceptForNormalMappings

Consolidation parameter that tells that some of the unchanged values should be considered for "add" part of resulting item delta. In particular, all values backed by strong, weak, and sourceless normal mappings. It is set for object template evaluation for focus or personas and assigned focus mappings evaluation. It may be renamed/changed in the future.

existingItemKnown

Consolidation parameter that tells that we know the existing item. It is false for resource object mappings that operate on non-full shadows.

v_ex

Presence of v₀ in existing item. (May be null if v₀ is not present there or if existing item is not known.)

Deletion of strongly-mandated values

Before the value is consolidated the following check is executed:

If v₀ is deleted by apriori delta and, at the same time, it is present in P or Z in connection with strong mapping (i.e. there is a strong mapping for v₀ that thinks the value should be added or unchanged) then we throw an exception. This is to avoid conflict between user-provided delta and a strong mapping. ^[2]

See IvwoConsolidator.checkDeletionOfStrongValue() method.

Value consolidation

First, we determine A₀ - origins that suggest we need to put v₀ to the delta "add" set. These are:

Condition	A₀ (add-suggesting origins for v₀)
addUnchanged	P₀ ∪ Z₀
¬ addUnchanged ∧ addUnchangedValuesExceptForNormalMappings	P₀ ∪ { z ∈ Z₀ \| z.isStrong ∨ z.isNormal ∧ z.isSourceless ∨ z.isWeak }
otherwise	P₀

Condition

A₀ (add-suggesting origins for v₀)

addUnchanged

P₀ ∪ Z₀

¬ addUnchanged ∧ addUnchangedValuesExceptForNormalMappings

P₀ ∪ { z ∈ Z₀ | z.isStrong ∨ z.isNormal ∧ z.isSourceless ∨ z.isWeak }

otherwise

P₀

There are the following cases:

Condition	Description	Action
A₀ ≠ ∅	At least one mapping indicates that v₀ is being added.	We invoke "value being added" part of the algorithm (see below).
A₀ = ∅	No mapping indicates that the value is being added.	We invoke "value not being added" part of the algorithm (see below).

Condition

Description

Action

A₀ ≠ ∅

At least one mapping indicates that v₀ is being added.

We invoke "value being added" part of the algorithm (see below).

A₀ = ∅

No mapping indicates that the value is being added.

We invoke "value not being added" part of the algorithm (see below).

Value being added

We have to check if we really have to add the value. See IvwoConsolidator.shouldAddValue() method.

ID	Condition	Description	Action
AW	All mappings in A₀ are weak.	We don’t know if we should apply v₀. We can do it only if there is no other value for the item.	We wait until all values are consolidated. Then weak mappings are considered. (I.e. we skip v₀ now.)
ExS	existingItemKnown ∧ v_ex ≠ null	We know the value v₀ is present in the existing item.	We skip addition of v₀.
ExA	¬existingItemKnown ∧ ∃z ∈ Z₀: ¬z.isWeak	We assume the value v₀ is present in the existing item. (Although we do not know the current value of the item, we have at least one non-weak mapping that thinks the value was unchanged.)	We skip addition of v₀.
NSwA	There is no strong mapping in A₀ and there is apriori delta for this item (with any value).	In order to prioritize user-specified values before the ones that are computed by mappings we skip v₀ and do not pass it to the resulting delta. ^[2]	We skip addition of v₀.
Other	(all other cases)	We should add v₀.	We put v₀ to the "add" set of the delta.

Condition

Description

Action

All mappings in A₀ are weak.

We don’t know if we should apply v₀. We can do it only if there is no other value for the item.

We wait until all values are consolidated. Then weak mappings are considered. (I.e. we skip v₀ now.)

ExS

existingItemKnown ∧ v_ex ≠ null

We know the value v₀ is present in the existing item.

We skip addition of v₀.

ExA

¬existingItemKnown ∧ ∃z ∈ Z₀: ¬z.isWeak

We assume the value v₀ is present in the existing item. (Although we do not know the current value of the item, we have at least one non-weak mapping that thinks the value was unchanged.)

We skip addition of v₀.

NSwA

There is no strong mapping in A₀ and there is apriori delta for this item (with any value).

In order to prioritize user-specified values before the ones that are computed by mappings we skip v₀ and do not pass it to the resulting delta. ^[2]

We skip addition of v₀.

Other

(all other cases)

We should add v₀.

We put v₀ to the "add" set of the delta.

From the metadata processing perspective, cases NSwA and ExS/ExA are different. In the former, the value v₀ is really discarded, along with its metadata. However, in the latter, metadata of v₀ should be taken into account and merged with the metadata of the existing value that is equivalent with v₀.

Value not being added

If Z₀ = ∅ ∧ M₀ ≠ ∅ i.e. no mapping thinks that v₀ should be kept and at least one thinks that v₀ should be removed, then the following is checked. (See IvwoConsolidator.shouldDeleteValue() method.)

ID	Condition	Description	Action
AW-Ex	All mappings in M₀ are weak and existing item has a value.	???	We skip deletion of v₀.
ExS	existingItemKnown ∧ v_ex = null	The value v₀ is not present in the existing item. We are requested to delete a value that is not there.	We skip deletion of v₀.
NSwA	There is no strong mapping in M₀ and there is apriori delta for this item (with any value).	In order to prioritize user-specified values before the ones that are computed by mappings we skip v₀ and do not pass it to the resulting delta. ^[2]	We skip deletion of v₀.
Other	(all other cases)	We should delete v₀.	We put v₀ to the "delete" set of the delta.

Condition

Description

Action

AW-Ex

All mappings in M₀ are weak and existing item has a value.

???

We skip deletion of v₀.

ExS

existingItemKnown ∧ v_ex = null

The value v₀ is not present in the existing item. We are requested to delete a value that is not there.

We skip deletion of v₀.

NSwA

There is no strong mapping in M₀ and there is apriori delta for this item (with any value).

In order to prioritize user-specified values before the ones that are computed by mappings we skip v₀ and do not pass it to the resulting delta. ^[2]

We skip deletion of v₀.

Other

(all other cases)

We should delete v₀.

We put v₀ to the "delete" set of the delta.

1. The implementation seems to be not quite correct when it comes to comparing values.

2. It is not quite clear if this behavior is 100% correct, because in this way we prioritize not only user-specified values but all values that were computed by (any) previously evaluated mappings. However, we are not going to remove this behavior now.

Was this page helpful?

YES NO

Thanks for your feedback