DELETE_BEHAVIOR PREVENT reports success and writes DELETE_BUT_KEEP_REFERENCES, destroying a stored DELETE_CASCADE

[ynnckw]

Summary

DELETE_BEHAVIOR PREVENT (and its long form DELETE_IF_NO_REFERENCES) is accepted by the grammar and documented in mxcli syntax domain-model.association.delete-behavior, but it is not written. The association ends up at the default DELETE_BUT_KEEP_REFERENCES, so an association that previously had DELETE_CASCADE loses it. mxcli reports Modified association.

In 0.16.0 this value could not be written either, but the attempt was a refusal. Now it silently overwrites a different, existing setting — and it does so while the user is trying to set the very behaviour that gets destroyed.

Version: v0.18.0 (2026-08-14), Windows, Mendix 11.12.2, Studio Pro closed, offline write against a throwaway copy.

Reproduction

Start from an association whose delete behaviour is DELETE_CASCADE:

mxcli -p copy.mpr -c "DESCRIBE ASSOCIATION MyModule.Child_Parent"
-- ... delete_behavior DELETE_CASCADE;

mxcli -p copy.mpr -c "CREATE OR MODIFY ASSOCIATION MyModule.Child_Parent \
  FROM MyModule.Child TO MyModule.Parent TYPE Reference OWNER Default \
  STORAGE column DELETE_BEHAVIOR PREVENT;"
-- Modified association: MyModule.Child_Parent

mxcli -p copy.mpr -c "DESCRIBE ASSOCIATION MyModule.Child_Parent"
-- ... delete_behavior DELETE_BUT_KEEP_REFERENCES;

Actual: DELETE_BUT_KEEP_REFERENCES — neither the requested value nor the previous one.

Expected: either DELETE_IF_NO_REFERENCES is written, or the statement is refused with an error and the stored behaviour is left untouched.

Measured 2026-08-15 on a Mendix 11.12.2 project, on a Reference association whose child side was stored as a cascading delete.

Note on the surrounding behaviour, which is correct

A CREATE OR MODIFY ASSOCIATION that omits delete_behavior now preserves it. Verified in the same session on an association sitting at DELETE_IF_NO_REFERENCES, which survived a COMMENT-only write unchanged. That is an improvement over 0.16.0, where an omitted delete_behavior reset to the default.

So the data loss is specific to naming PREVENT / DELETE_IF_NO_REFERENCES explicitly. Line anchors also survive both cases, which is what made the remaining loss easy to miss.