Remove COMPOSITION invariant preventing context for persistent Compositions


THis needs to be relaxed according to needs identified by implementers and described in


Boštjan Lah
January 31, 2017, 11:49 AM

I also think we should just go ahead with this.

Ian McNicoll
January 31, 2017, 12:33 PM

Agreed. It should not have any backward compatibility issues since any current AQL would simply not be able to reference 'context'.

Erik Sundvall
February 1, 2017, 3:56 AM

Good, go ahead!

Sebastian Iancu
February 3, 2017, 7:00 AM

Reading duplicate comments I thought we should also indicate somewhere in specs how should we than consider/detect persistent compositions in the new situation (see comments):
heath.frankel Heath Frankel added a comment - 17/Mar/16 8: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.

Thomas Beale
February 8, 2017, 1:04 PM

I have completed the work on this now. Please see the links in the 'Execution' tab above. The changes are the most minimal possible, rather than changing a lot of text to do with e.g. Composition.category, which will need to come later.
NB: normally 'acceptance' should only be made when you agree with the actual changes.


Thomas Beale

Raised By

Thomas Beale


Affects versions