Allow persistent Compositions to include event context.


See and
Consider whether other categories of Composition are needed.


Ian McNicoll
March 17, 2016, 7:40 AM

The two choices are, I think,

Simply to remove the invariant, but I guess this may cause some backwards compatibility issues since a number of mandatory /context attributes then come into play.

The alternative is to add a new episode_persistent category which indicates that the commit strategy is persistent i.e continual updates of the same composition instance, but without the invariant. That might be simpler and potentially less disruptive.

Heath Frankel
March 17, 2016, 7:53 AM

My concern with a new code is then deciding which composition archetypes are persistent or episode_persistent, take care plan for example.
If the invariant is removed/changed to 0..1, then we can use the rm_version to determine if we should be enforcing 0..0 or allowing 0..1. We are opening the constraint which should be more acceptable than closing the constraint, it only affect new systems sending to old systems. We shouldn't be holding back progress.

Ian McNicoll
March 17, 2016, 7:57 AM

I hadn't thought of changing invariant rule to make event_context 0..1 - I think that solves the problem very neatly.
+1 from me.

Bjørn Næss
March 17, 2016, 11:54 AM

Is this only related to the tooling?
If not: Where can I find the definition that tells that a Composition of type persistent should not have event_context?
I find a textual description here:
This states that event_context is not suitable for i.e. persistent compositions.

Ian McNicoll
March 17, 2016, 12:18 PM


Is_persistent_validity: is_persistent implies context = Void



Thomas Beale

Raised By

Thomas Beale


Affects versions