Sync ako/mxcli: OData complex types, project-language DESCRIBE, modelling defaults and syntax coverage

[ako]

7 commits from the fork's main, on top of the last sync (def6d23). Grouped by theme.

OData external entities lost every complex-type property

CREATE OR MODIFY EXTERNAL ENTITIES FROM dropped every property whose type was an OData ComplexType. The entity imported with only its key, exec reported "1 created, 0 failed" and printed nothing, and mx check reported 0 errors — the loss surfaced much later as CE1613 on a page written against the attributes Studio Pro would have made.

• Flatten as Studio Pro does (745d24e, fixes CREATE OR MODIFY EXTERNAL ENTITIES FROM silently drops OData ComplexType properties from external namespaces #1118) — mdl/types/edmx.go never parsed <ComplexType> at all, so a complex property was indistinguishable from an unknown type and fell through the !strings.HasPrefix(p.Type, "Edm.") drop. The report says "only cross-namespace"; in fact every complex type was dropped, since nothing named Edm.* is complex. Now one attribute per leaf, named <property>_<leaf>, read over the OData path <property>/<leaf>, resolved by qualified name — one document may declare Quantity in two namespaces. Measured on 11.12.1: the path form is 0 errors, the underscore form and a bogus path are both 4× CE6615, so mxbuild genuinely validates into the complex type. The pre-fix control — attributes simply absent — is 0 errors, which is why the drop was invisible. Anything still unmappable is now named with a reason instead of vanishing.
• Corrected against the live TripPin contract (318cf90) — the first pass was verified against a synthetic two-property complex type that passed mx check clean; the integration suite's TripPin contract found four defects in it, at 11 errors. TripPin has what the fixture lacked: a base complex type, two derived from it, a nested complex property, an Edm.GeographyPoint, and both a top-level entity set and types derived from it. (1) Mendix imports a complex type's own properties only — the line is inheritance, not path syntax. (2) !strings.HasPrefix(t, "Edm.") is not the supported-type test: Edm.GeographyPoint passes it and is CE6622; the importable primitives are now a closed set. (3) Filterable/Sortable follow the entity set, and CE6630 fires in both directions. (4) Inherited and unsupported properties are reported by name and reason. TripPin now imports at 0 errors, down from 11, each rule with a control.

DESCRIBE read texts in the wrong language

• Enumeration captions (ef99d39, fixes DESCRIBE ENUMERATION returns empty captions for values that have captions defined in Studio Pro #1113) — every value came back as MyValue '' on any project whose DefaultLanguageCode is not en_US. A caption is a Texts$Text and Mendix has no language-neutral text, so a hardcoded en_US lookup simply missed. The write side already resolved the project's language (Captions written via MDL always land as en_US — breaks projects whose only/default language isn't en_US #970) and the widget read side was fixed for the same reason (describe PAGE outputs default Dutch placeholder 'Tekst' instead of actual widget text content #702); the enumeration read was the site neither sweep reached. The output was also destructive: fed back through exec it reported "Modified enumeration" and emptied the stored translations. After the fix the same round trip reports "Unchanged enumeration" and the unit is byte-identical.
• Swept across the executor (b6b6560b) — the same pattern appears at every GetTranslation("en_US") and every en_US lookup followed by a bare map-range. Two distinct defects hid behind it: sites with no fallback dropped the text entirely (describe entity silently lost a validation feedback message), and sites with a map-range fallback returned a different language per run, making DESCRIBE output undiffable on a multi-language project — invisible to a single-language repro. All now go through one resolver: project language, then en_US, then the non-empty translation with the lowest language code. An en_US project is unaffected at every site, and there are no hardcoded en_US reads left in mdl/executor.

Workflows and view entities as the default modelling choice

• Stated in the guidance (75da19cd) — both are first-class in Mendix and both get reinvented in microflows by default, because the microflow version works: it passes check, it builds, and nothing flags it. No command can prompt for either — lint cannot know a Status attribute is standing in for a state machine — so it has to be in the guidance or it reaches an agent only when the user already knew to ask. A business process with human steps is a WORKFLOW, not a status attribute plus microflows; an aggregation is a VIEW ENTITY (OQL the database executes), not a microflow that retrieves every row to produce one number — which gets slower exactly as the app succeeds. Stated in all three descriptions of the procedure, as the gates already are, and held together by a test with a control.

mxcli syntax coverage

• View entities and nanoflow restrictions (c9b9c45) — VIEW ENTITY had no topic at all; the registry knew the words only as a keyword on errors.execution, so an agent told to prefer one got nothing back. Three topics under domain-model (the document, its OQL, and why selecting an id under an alias is the association), filed there rather than beside the top-level oql topic, which is a different thing — running a query against a live runtime. Content taken from measured behaviour in mdl-examples/bug-tests rather than restated from the skill. Separately, microflow.nanoflow existed but said "same syntax as microflow", which is the half that never causes a problem; it now lists what mxcli check actually refuses, read off nanoflow_validation.go. One claim was wrong on the first pass and the grammar caught it: there is a GRANT EXECUTE ON NANOFLOW.
• ALTER STYLING and UPDATE WIDGETS (c4d69ae) — an audit of all 163 registered topics against every grammar statement alternative found the CREATE and DROP surfaces fully covered and two shipped, model-mutating statements with no registry presence at all. Both are the in-place alternative to rewriting a whole page, which is exactly where being undiscoverable costs the most: an agent that cannot find them reaches for CREATE OR REPLACE PAGE, whose diff is the entire document and which drops anything MDL cannot yet spell. Each claim read off the source rather than assumed. Deliberately not added: the session/REPL utilities, which drive the tool rather than author the model

[github-actions]

AI Code Review

Critical Issues

None found.

Moderate Issues

None found.

Minor Issues

• Syntax coverage completeness: While the PR adds syntax topics for VIEW ENTITY, ALTER STYLING, and UPDATE WIDGETS, I don't see corresponding additions in the doctest files (mdl-examples/doctype-tests/). For full-stack consistency, syntax features should have working examples in doctest files to verify they parse and execute correctly. The PR does add bug test files which are appropriate for the fixes, but the syntax features themselves would benefit from positive doctest examples.

• PR scope breadth: The PR covers four distinct themes (OData complex types, language handling, guidance documentation, syntax coverage). While all are valuable improvements, they address largely unrelated areas of the codebase. Following the atomicity principle, these might be better split into separate PRs for easier review and tracking.

What Looks Good

• OData complex types fix: Excellent resolution of a serious silent failure mode. The fix properly parses ComplexType elements, flatt them as Studio Pro does (using <property>_<leaf> naming), uses qualified names for resolution across namespaces, correctly handles inheritance (importing own properties only), uses a closed set of supported types, properly handles filterable/sortable semantics, and reports unmappable properties with reasons instead of silently dropping them. Comprehensive tests verify the behavior against both synthetic and real-world (TripPin) contracts.

• Language handling fix: Thoroughly addresses the issue of DESCRIBE returning texts in the wrong language. Replaces all hardcoded "en_US" lookups with a consistent resolver (project language → en_US → lowest language code), makes the output deterministic by sorting language codes, and applies the fix broadly across enumerations, entities, validation rules, and other text-bearing elements. Tests verify correct behavior in mono-lingual, multi-lingual, and fallback scenarios.

• Guidance documentation: Appropriately elevates WORKFLOW and VIEW ENTITY as first-class modelling choices in the documentation, helping prevent users from reinventing these patterns in microflows.

• Syntax coverage improvements: Adds missing syntax topics for already-implemented features (VIEW ENTITY, ALTER STYLING, UPDATE WIDGETS, nanoflow restrictions), improving discoverability and reducing the tendency to use less optimal patterns like CREATE OR REPLACE PAGE.

• Code quality: The changes follow established patterns, use proper error handling, and include comprehensive test coverage. The language fix in particular shows good engineering practice by identifying a systemic issue and applying a consistent solution across the codebase.

• Test coverage: Adds meaningful unit and integration tests for both fixes, including testing against real-world contracts (TripPin) and verifying error reporting behavior.

Recommendation

---

Automated review via OpenRouter (Nemotron Super 120B) — workflow source