ALTER ENTITY ... ADD ATTRIBUTE on a view entity writes a stored attribute (CE6770), and check does not catch it

[marclehane-creator]

Version: mxcli 0.23.0 (Windows), Mendix 11.12.1
Repro app: mxcli new Repro --version 11.12.1 — nothing else needed

What happens

ALTER ENTITY ... ADD ATTRIBUTE on a view entity writes an ordinary stored attribute. The
attribute has no binding to an OQL column, so Studio Pro rejects the model with
CE6770 "View Entity is out of sync with the OQL Query." — and mxcli check -p does not report it.

Repro

create entity MyFirstModule.Sale (
  Amount: Integer,
  CustomerName: String(200)
);
create view entity MyFirstModule.SaleStats (
  CustomerName: String(200),
  Total: Integer
) as (
  SELECT
    s.CustomerName as CustomerName,
    SUM(s.Amount) as Total
  FROM MyFirstModule.Sale as s
  GROUP BY s.CustomerName
);

mx check → 0 errors.

Now add a column the way the tool suggests:

ALTER ENTITY MyFirstModule.SaleStats ADD ATTRIBUTE Region: String(200);

Added attribute 'Region' to entity MyFirstModule.SaleStats

exit 0.

mx check → [error] [CE6770] "View Entity is out of sync with the OQL Query." at Entity 'MyFirstModule.SaleStats'

The mechanism

Reading the entity's unit out of the .mpr (BSON), the three attributes differ:

attribute	Value.$Type	Reference
CustomerName (from OQL)	DomainModels$OqlViewValue	CustomerName
Total (from OQL)	DomainModels$OqlViewValue	Total
Region (added by ALTER)	DomainModels$StoredValue	(none)

Reference is the binding between a view attribute and its OQL column alias. Adding the matching
column to the OQL does not clear CE6770 — the alias, type and ordinal position can all line up and
it still fails, because the attribute is still a StoredValue.

Why it costs more than it looks

• mxcli check -p <mpr> is silent, so the model reads as applied and validated until mx check runs.
• The CE6770 message names only the entity, never the attribute, so it reads as a structural
  problem with the query. On a real 31-column view I burned three wrong hypotheses first (column
  ordering, the String(200) derived-column rule, a missing mapping on the ViewEntitySourceDocument
  unit — that unit holds nothing but Oql).
• mxcli's own guidance points at this command. Re-running CREATE OR MODIFY on an existing view
  entity prints: "to add or change a member use 'alter entity … add attribute …' (leaves the rest
  intact)" — which is exactly the broken path for a view.

Expected

On a view entity, ADD ATTRIBUTE should either write an OqlViewValue bound to the matching alias,
or refuse with a message explaining that view attributes come from the OQL.

Workaround

Rewrite each Value to {$Type: DomainModels$OqlViewValue, Reference: <attribute name>} by direct
BSON write, then recompute Unit.ContentsHash in the .mpr (base64 of sha256 over the unit bytes,
keyed by UnitID stored as GUID bytes_le). mx check clean afterwards.

Together with the two sibling issues I am filing (an AS ROLE alias that DESCRIBE emits but the
parser rejects, and apostrophes in OQL comments producing false MDL030), the net effect on 0.23.0 is
that adding one column to an existing, documented view entity has no supported path.