Implement CTerminologyCode.constraint as String by MattijsK · Pull Request #761 · openEHR/archie

MattijsK · 2026-03-05T13:02:04Z

Summary

This PR fixes #643. As there was a difference between the openEHR specification and Archie. So it changes CTerminologyCode.constraint from List<String> to String.

Changes

Core model (`CTerminologyCode`)

constraint field changed from List<String> to String; getConstraint() now returns String
addConstraint(String) removed; setConstraint(String) takes a single value
getConstraintAsList() added as a convenience method for call sites that need list semantics,
returning a singleton list or an empty list

Abstract primitive object interface (`CPrimitiveObject`)

getConstraint() return type generalised to Object to accommodate the now-divergent constraint
types across subclasses
getConstraintAsList() added as abstract, implemented in all subclasses; annotated @JsonIgnore
so it is not serialised as a separate property
addConstraint() removed from the abstract interface

ADL 1.4 → ADL 2 conversion (`ADL14TermConstraintConverter`, `Adl14PrimitivesConstraintParser`)

ADL 1.4 allows inline multi-code constraints (e.g. [local::at0001, at0002] and
[snomed-ct::12345, 67890]) which have no direct ADL 2 equivalent. These are handled in a
two-phase approach:

The parser stores the raw codes in a new @JsonIgnore @XmlTransient List<String> pendingCodes
field on CTerminologyCode — used only during conversion, never serialised
The converter reads pendingCodes and creates a proper value set (ac-code) from them, setting
the resulting ac-code as the single constraint
External multi-code constraints are normalised to full term code refs ([terminology::code]) by
the parser so the converter can treat all pending codes uniformly
The converter is restructured into convertCTerminologyCode (single-code),
convertMultiCodeTerminologyCode (multi-code), and convertAssumedValue (shared assumed-value
logic)

Serialisation

JSON deserialisation of the old array format ("constraint": ["at1"]) is handled by the existing
UNWRAP_SINGLE_VALUE_ARRAYS Jackson feature

…y_contstraint_type_to_string

codecov · 2026-04-09T07:46:25Z

Codecov Report

❌ Patch coverage is 74.28571% with 36 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.38%. Comparing base (d756c1a) to head (f0a3c43).
⚠️ Report is 1 commits behind head on 670_feature_archie_4_major_version.

Files with missing lines	Patch %	Lines
...dap/archie/adl14/ADL14TermConstraintConverter.java	70.42%	12 Missing and 9 partials ⚠️
.../nedap/archie/aom/primitives/CTerminologyCode.java	56.25%	2 Missing and 5 partials ⚠️
.../nedap/archie/adl14/PreviousConversionApplier.java	33.33%	1 Missing and 1 partial ⚠️
...er/adl/constraints/CTerminologyCodeSerializer.java	50.00%	0 Missing and 2 partials ⚠️
...a/com/nedap/archie/adl14/ADL14NodeIDConverter.java	0.00%	0 Missing and 1 partial ⚠️
...a/com/nedap/archie/adl14/aom14/CDVOrdinalItem.java	0.00%	1 Missing ⚠️
...main/java/com/nedap/archie/aom/utils/AOMUtils.java	0.00%	0 Missing and 1 partial ⚠️
.../archie/creation/ExampleJsonInstanceGenerator.java	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                           Coverage Diff                            @@
##             670_feature_archie_4_major_version     #761      +/-   ##
========================================================================
+ Coverage                                 72.34%   72.38%   +0.03%     
- Complexity                                 7189     7193       +4     
========================================================================
  Files                                       678      678              
  Lines                                     23267    23299      +32     
  Branches                                   3764     3786      +22     
========================================================================
+ Hits                                      16833    16864      +31     
+ Misses                                     4707     4704       -3     
- Partials                                   1727     1731       +4

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

VeraPrinsen · 2026-04-10T09:25:01Z

    public abstract void setAssumedValue(ValueType assumedValue);

-    public abstract List<Constraint> getConstraint();
+    public abstract Object getConstraint();


I think it should be possible to do:

Suggested change

public abstract Object getConstraint();

public abstract Constraint getConstraint();

Meaning that when classes extend CPrimitiveObject, they have to edit the type of constraint, for example CBoolean has to do:
public class CBoolean extends CPrimitiveObject<List<Boolean>, Boolean>

Then we also don't need the convenience method getConstraintAsList, as getConstraint will return a String for CTerminologyCode, but a List for CBoolean.

addConstraint(Constraint constraint) will have to be removed from CPrimitiveObject, but can then be added as a convenience method to objects that have a list as constraint, like CBoolean.

For me this feels a bit more like how the specifications intended it, instead of a little workaround.

I changed the type here back to Constraint. Can you check if it makes more sense now?
I still kept getConstraintAsList in though.

VeraPrinsen · 2026-04-13T08:49:19Z

    @Deprecated
    public boolean isValidValue(TerminologyCode value) {
-        if(getConstraint().isEmpty()) {
+        if(getConstraint() == null || getConstraint().isEmpty()) {


I feel the functionality has changed here, because previously if the constraint list contained an empty string this if statement wasn't true and now it is. And also further in the code I don't see any reason why a getConstraint() of an empty string would return true by default.

VeraPrinsen · 2026-04-13T08:53:24Z

        List<String> otherValueSet = otherCode.getValueSetExpanded();

-        if(constraint.size() != 1) {
+        // TODO: does this need to be removed/reworded or anything else?


Yes, I think this should be reworded. I don't see any specific wording for this in the specifications, so I guess we can just change the wording?

I think these checks are completely changed now and the objects would actually conform to if the constraint of the parent or itself are null now. I changed this, please check if it makes sense to you.

VeraPrinsen · 2026-04-13T09:15:45Z

    @Override
    public void serialize(CTerminologyCode cobj) {
-        if (!cobj.getConstraint().isEmpty()) {
+        if (cobj.getConstraint() != null && !cobj.getConstraint().isEmpty()) {


Suggested change

if (cobj.getConstraint() != null && !cobj.getConstraint().isEmpty()) {

if (cobj.getConstraint() != null) {

I think empty strings would just be used in the code previously, so I think we shouldn't change that.

VeraPrinsen · 2026-04-13T09:58:53Z

-            } else if (cObject instanceof CPrimitiveObject) {
-                CPrimitiveObject<?, ?> cPrimitiveObject = (CPrimitiveObject<?, ?>) cObject;
-                List<?> constraint = cPrimitiveObject.getConstraint();
+            } else if (cObject instanceof COrdered) {


If we keep the getConstraintAsList() it is maybe better to use that instead, in the case (that will probably never happen) that a new CPrimitiveObject based on an Interval constraint is introduced.

I think I can keep it the way it is, I added a clarifying comment though.

VeraPrinsen · 2026-04-13T10:01:44Z


    private static RMObjectValidationMessage createValidationMessage(Object value, String pathSoFar, CPrimitiveObject<?, ?> cobject) {
-        List<?> constraint = cobject.getConstraint();
+        List<?> constraint = cobject.getConstraintAsList();


Or maybe just use getConstraint() and instead of checking if the constraint.size() == 1, check if the constraint is a list (and maybe has more than 1 element).

I don't think this makes much sense. I still kept in getConstraintAsList, so this keeps it the simplest.

VeraPrinsen · 2026-04-13T10:03:02Z


    private boolean isValidValue(CTerminologyCode terminologyCode, TerminologyCode value) {
-        if(terminologyCode.getConstraint().isEmpty()) {
+        if(terminologyCode.getConstraint() == null || terminologyCode.getConstraint().isEmpty()) {


Suggested change

if(terminologyCode.getConstraint() == null || terminologyCode.getConstraint().isEmpty()) {

if(terminologyCode.getConstraint() == null

Again I don't think previously an empty string would by default return true.

Make it Constraint again instead of Object

VeraPrinsen · 2026-04-20T12:18:48Z

-    public abstract List<Constraint> getConstraint();
+    public abstract Constraint getConstraint();

-    public abstract void setConstraint(List<Constraint> constraint);


This abstract method can stay, but just with the parameter Constraint instead of List

VeraPrinsen · 2026-04-20T13:38:45Z

+    /** Temporary storage for multi-code ADL 1.4 constraints during conversion. Never serialized. */
+    @JsonIgnore
+    @XmlTransient
+    private List<String> pendingCodes;


When parsing a ADL1.4 archetype, the codes will end up here. But when you try and serialize the archetype again, the constraint of the defining code now stays empty.

So maybe we should add in the serializer that the pendingCodes should be converted into a list of strings for the constraint. Or we should maybe have two separate CTerminologyCode classes. One for ADL1.4 and one for ADL2.

ctermcode.constraint type to string

fe7c286

MattijsK changed the base branch from master to 670_feature_archie_4_major_version March 5, 2026 13:22

MattijsK added 3 commits April 8, 2026 12:38

Add extra checks

58fd4b8

Merge branch '670_feature_archie_4_major_version' into 643_terminolog…

a55cdd9

…y_contstraint_type_to_string

Fix parsing and converting of adl14 term codes

1cd0f21

MattijsK changed the title ~~ctermcode.constraint type to string~~ Implement CTerminologyCode.constraint as String Apr 9, 2026

MattijsK marked this pull request as ready for review April 9, 2026 08:50

MattijsK linked an issue Apr 9, 2026 that may be closed by this pull request

CTerminologyCode.constraint has incorrect type #643

Open

VeraPrinsen self-requested a review April 10, 2026 08:57

VeraPrinsen reviewed Apr 13, 2026

View reviewed changes

MattijsK added 4 commits April 14, 2026 12:36

Change constraint type in CPrimitiveObject

462743b

Make it Constraint again instead of Object

Requested changes

1551e68

Add backwards compatibility tests

4d80e8e

Move and rename test

f0a3c43

VeraPrinsen reviewed Apr 21, 2026

View reviewed changes

	public abstract Object getConstraint();
	public abstract Constraint getConstraint();

	if (cobj.getConstraint() != null && !cobj.getConstraint().isEmpty()) {
	if (cobj.getConstraint() != null) {

	if(terminologyCode.getConstraint() == null \|\| terminologyCode.getConstraint().isEmpty()) {
	if(terminologyCode.getConstraint() == null

Conversation

MattijsK commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Core model (CTerminologyCode)

Abstract primitive object interface (CPrimitiveObject)

ADL 1.4 → ADL 2 conversion (ADL14TermConstraintConverter, Adl14PrimitivesConstraintParser)

Serialisation

Uh oh!

codecov Bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MattijsK commented Mar 5, 2026 •

edited

Loading

Core model (`CTerminologyCode`)

Abstract primitive object interface (`CPrimitiveObject`)

ADL 1.4 → ADL 2 conversion (`ADL14TermConstraintConverter`, `Adl14PrimitivesConstraintParser`)

codecov Bot commented Apr 9, 2026 •

edited

Loading