mxcli version
mxcli version v0.18.0 (2026-08-14T20:29:13Z)
Mendix version
10.24.24.119653
Severity
Medium.
No data is lost and nothing is written incorrectly — but DESCRIBE PAGE output is
not round-trippable for any page hitting this, and it fails at mxcli check with an
error that names the wrong thing, so the cause is not obvious from the message.
It also quietly misinforms a reader about how a page gets its data: a widget fed by a
microflow is rendered as if it read the database directly.
Symptoms
Both are the same defect — the database from keyword is emitted for a datasource that
is not "database over an entity" — but they fail differently.
1. Entity slot left blank
gallery gallery2 (DataSource: database from , Selection: Single, Class: '...') {
^ nothing here
Also seen with a constraint still attached, which makes it look even more like valid
output:
DataSource: database from where not(Module.Assoc_A/Module.B),
mxcli check on that:
statement 1: page '...' has reference errors:
- entity not found: from
The parser has taken the keyword from as the entity name.
2. A microflow emitted in the entity slot
line line1 (
DataSource: database from Module.DS_GetSomeList,
...
Module.DS_GetSomeList is a microflow (returns a List), not an entity.
mxcli check:
statement 1: page '...' has reference errors:
- entity not found: Module.DS_GetSomeList
The error blames a missing entity when the real fault is the wrong datasource keyword —
it should have been DataSource: microflow Module.DS_GetSomeList.
DESCRIBE PAGE gets this right elsewhere on the very same page, which is what makes it
a serializer bug rather than a missing feature:
gallery gallery1 (DataSource: microflow Module.DS_GetLocatieListForMap) { -- correct
Steps to reproduce
Symptom 1 needs a Gallery whose datasource is scoped to a surrounding context rather
than a bare entity (on the project where this was found: seven nested galleries, each
listing the children of the row selected in the gallery one level up).
Symptom 2 needs a pluggable charting widget (a Line chart series) bound to a microflow
datasource.
mxcli -p MyApp.mpr -c "DESCRIBE PAGE MyModule.SomePage" > out.mdl
grep -n "database from" out.mdl # blank entity, or a microflow name
mxcli check out.mdl -p MyApp.mpr --references
Expected: Check passed! — describing a page and checking the result should be a
no-op. Actual: entity not found: from, or entity not found: <the microflow>.
Expected behaviour
DESCRIBE PAGE output re-checks clean. Specifically:
- A microflow datasource is emitted as
DataSource: microflow Module.Flow, never as
database from Module.Flow.
- A datasource whose entity cannot be resolved is never emitted as a bare
database from with an empty slot. Emit the resolved entity, or a comment naming
what could not be serialised — anything the parser will not silently read as an
entity called from.
Actual behaviour
Measured on two pages in one project, v0.18.0, 2026-08-20:
| Page |
Line |
Emitted |
Reality |
MyModule.Parent_Edit |
6 occurrences |
database from (blank) |
gallery over a context-scoped source |
MyModule.Parent_Edit |
1 occurrence |
database from where not(...) |
same, with constraint retained |
MyModule.Dashboard |
1 occurrence |
database from MyModule.DS_GetSomeList |
a microflow returning a List |
Both pages fail mxcli check on their own DESCRIBE output.
Workaround
Do not use DESCRIBE PAGE output as a round-trip script. Use targeted ALTER PAGE
operations (SET / INSERT / REPLACE / DROP) instead, which patch in place and do
not require re-emitting the page.
To learn what a widget's datasource really is, read the stored model:
mxcli bson dump -p MyApp.mpr --type page --object MyModule.SomePage > page.json
grep -n 'MicroflowSource\|CustomWidgetXPathSource\|DataViewSource' page.json
Related
Found while testing a separate, more serious defect —
DESCRIBE PAGE silently omits List View specialization templates, reported in
#940. This datasource bug is what blocks that
report's round-trip test before the Mendix-11 page-parameter guard does.
Diagnostic bundle
Yes — mxcli-diag-20260820-132332.tar.gz, available on request. Not attached, because
it contains client model data.
Note on anonymisation
Module and document names above are placeholders. Counts, line positions, emitted
text and error messages are faithful to the real measurement.
mxcli version
Mendix version
10.24.24.119653Severity
Medium.
No data is lost and nothing is written incorrectly — but
DESCRIBE PAGEoutput isnot round-trippable for any page hitting this, and it fails at
mxcli checkwith anerror that names the wrong thing, so the cause is not obvious from the message.
It also quietly misinforms a reader about how a page gets its data: a widget fed by a
microflow is rendered as if it read the database directly.
Symptoms
Both are the same defect — the
database fromkeyword is emitted for a datasource thatis not "database over an entity" — but they fail differently.
1. Entity slot left blank
Also seen with a constraint still attached, which makes it look even more like valid
output:
mxcli checkon that:The parser has taken the keyword
fromas the entity name.2. A microflow emitted in the entity slot
Module.DS_GetSomeListis a microflow (returns a List), not an entity.mxcli check:The error blames a missing entity when the real fault is the wrong datasource keyword —
it should have been
DataSource: microflow Module.DS_GetSomeList.DESCRIBE PAGEgets this right elsewhere on the very same page, which is what makes ita serializer bug rather than a missing feature:
Steps to reproduce
Symptom 1 needs a Gallery whose datasource is scoped to a surrounding context rather
than a bare entity (on the project where this was found: seven nested galleries, each
listing the children of the row selected in the gallery one level up).
Symptom 2 needs a pluggable charting widget (a Line chart series) bound to a microflow
datasource.
Expected:
Check passed!— describing a page and checking the result should be ano-op. Actual:
entity not found: from, orentity not found: <the microflow>.Expected behaviour
DESCRIBE PAGEoutput re-checks clean. Specifically:DataSource: microflow Module.Flow, never asdatabase from Module.Flow.database fromwith an empty slot. Emit the resolved entity, or a comment namingwhat could not be serialised — anything the parser will not silently read as an
entity called
from.Actual behaviour
Measured on two pages in one project, v0.18.0, 2026-08-20:
MyModule.Parent_Editdatabase from(blank)MyModule.Parent_Editdatabase from where not(...)MyModule.Dashboarddatabase from MyModule.DS_GetSomeListBoth pages fail
mxcli checkon their ownDESCRIBEoutput.Workaround
Do not use
DESCRIBE PAGEoutput as a round-trip script. Use targetedALTER PAGEoperations (
SET/INSERT/REPLACE/DROP) instead, which patch in place and donot require re-emitting the page.
To learn what a widget's datasource really is, read the stored model:
Related
Found while testing a separate, more serious defect —
DESCRIBE PAGEsilently omits List View specialization templates, reported in#940. This datasource bug is what blocks that
report's round-trip test before the Mendix-11 page-parameter guard does.
Diagnostic bundle
Yes —
mxcli-diag-20260820-132332.tar.gz, available on request. Not attached, becauseit contains client model data.
Note on anonymisation
Module and document names above are placeholders. Counts, line positions, emitted
text and error messages are faithful to the real measurement.