Package com.evolveum.midpoint.prism.equivalence

Interface EquivalenceStrategy

All Known Implementing Classes:
MidpointProvenanceEquivalenceStrategy, ParameterizedEquivalenceStrategy
public interface EquivalenceStrategy
A strategy used to determine equivalence of prism items and values. This is quite generic interface. We expect that usually it will not be implemented directly, because comparing prism structures is a complex undertaking. The usual approach will be using ParameterizedEquivalenceStrategy that contains a set of parameters that drive equals/hashCode methods built into prism structures. However, if anyone would need the ultimate flexibility, he is free to implement this interface from scratch. (Note that not all methods in prism API accept this generic form of equivalence strategy. For example, diff(..) methods are limited to ParameterizedEquivalenceStrategy at least for now.)
See Also:

  • Field Details

    • LITERAL

      static final ParameterizedEquivalenceStrategy LITERAL
      Currently the highest level of recognition. Roughly corresponds to comparing serialized forms of the data. Useful e.g. for comparing values for the purpose of XML editing. Ignores aspects that are not covered by serialization e.g. definitions, parent objects, origin, immutability flag, etc.

    • DATA

      static final ParameterizedEquivalenceStrategy DATA
      Captures the data. Ignores minor serialization-related things that are not relevant for the parsed data, like namespace prefixes. Also ignores the difference between null and default relation. Currently this is the default for equals/hashCode.

    • REAL_VALUE

      static final ParameterizedEquivalenceStrategy REAL_VALUE
      Captures the "real value" of the data: it is something that we consider equivalent so that if prism values A and B have the same real value, we do not want to be both present in the same multi-valued item (like assignment, roleMembershipRef, or whatever). However, in reality, we usually take container IDs (if both are present) into account, so if PCV A1 and A2 have equal content but different IDs they are treated as different. This is reflected in REAL_VALUE_CONSIDER_DIFFERENT_IDS strategy.

    • REAL_VALUE_CONSIDER_DIFFERENT_IDS

      static final ParameterizedEquivalenceStrategy REAL_VALUE_CONSIDER_DIFFERENT_IDS
      As REAL_VALUE but taking different PCV IDs into account (if both are present). Currently, this is the default for delta application. See ParameterizedEquivalenceStrategy.FOR_DELTA_ADD_APPLICATION and ParameterizedEquivalenceStrategy.FOR_DELTA_DELETE_APPLICATION. It is not quite clear if this strategy is well-formed. Often we want to differentiate PCV IDs but only on some levels, e.g. for assignments, but not on others, e.g. inside assignments. This has to be sorted out.

    • REAL_VALUE_CONSIDER_DIFFERENT_IDS_NATURAL_KEYS

      @Experimental static final ParameterizedEquivalenceStrategy REAL_VALUE_CONSIDER_DIFFERENT_IDS_NATURAL_KEYS
      Same as REAL_VALUE_CONSIDER_DIFFERENT_IDS but also takes natural keys into account. However, natural keys can be considered only if there are PCV ids present in first value. This is to avoid item paths with null segments or natural keys being added to item path. This is a bit experimental.

    • IGNORE_METADATA

      static final ParameterizedEquivalenceStrategy IGNORE_METADATA
      This is something between DATA and REAL_VALUE: ignores operational items and values, container IDs, value metadata (just like REAL_VALUE) but takes reference filters and reference resolution options (time, integrity), as well as item names into account (like DATA). It is not quite clear whether and when to use this strategy.

    • NOT_LITERAL

      @Deprecated static final ParameterizedEquivalenceStrategy NOT_LITERAL
      Deprecated.

  • Method Details