Skip to content

fix(describe): name the entity an association data source reaches as its context - #1572

Open
stagknee wants to merge 1 commit into
mendixlabs:mainfrom
stagknee:fix/describe-context-association
Open

stagknee wants to merge 1 commit into
mendixlabs:mainfrom
stagknee:fix/describe-context-association

Conversation

@stagknee

Copy link
Copy Markdown
Contributor

Closes #1571.

What it fixes

A data view, list view, gallery or data grid bound over an association printed the association as its context, -- Context: $currentObject (Shop.Order_Customer), instead of the entity the association reaches, (Shop.Customer). The datasource line itself is unchanged.

How

  • dataSourceEntityContext gets an association case, following 6e59e0e for flow sources. It returns the destination when the stored source has one, and otherwise the old reference.
  • rawDataSource.Destination is filled by associationSourceDestination, which reads EntityRef.Steps[last].DestinationEntity. Studio Pro and mxcli both store that value, and I confirmed it with bson dump for a reference, the reverse direction and a reference set. It is correct in both directions, for reference sets, and for a destination that specializes the association's end. alter page's entityFromEntityRef already reads it.
  • Both places that build an association source set it: dsTypeAssociation and parseContextSource. The second also covers the DataViewSource and the pluggable XPath source (DESCRIBE PAGE emits 'database from' for non-database datasources, producing invalid MDL #941).
  • associationRefForContext, the one consumer that compares the context's module, now sees the destination's module. That only differs for a cross-module association, and the result can only be better.
  • Also included: a CHANGELOG entry (Fixed), a finding in findings/mdl-executor/, and mdl-examples/bug-tests/1571-describe-context-association.mdl (expected lines in the header; the Go tests carry the assertion).

Evidence

  • Tests: cmd_pages_describe_assoc_context_test.go has six describe cases covering:

    • a data view, gallery, data grid and list view;
    • the owner side and the reverse side;
    • a reference set, with the selection variable kept.

    It also has a pluggable-source case, a fallback (no stored destination), and database and flow controls.

  • Control run: against the code on main, the seven association and pluggable cases fail with the reported symptom, and the controls and fallback pass. All pass with the fix.

  • Real run (Mendix 11.12.5 scratch app):

    Widget v0.26.0 this branch
    data view over Order_Customer (Shop.Order_Customer) (Shop.Customer)
    gallery / data grid / list view over Order_Line (Shop.Order_Line) (Shop.OrderLine)
    list view from the Customer side (Shop.Order_Customer) (Shop.Order)

    The DataSource: text is identical. Re-running the describe output reports Unchanged page, and mx check reports 0 errors.

  • Tests and vet: go test ./mdl/conformance/ passes. go test ./mdl/executor/ shows the same 28 pre-existing Windows failures as main (identical lists). go vet and gofmt are clean.

  • Linux (golang:1.26.6-bookworm, ANTLR 4.13.2): make grammar build test check-mdl check-findings check-conformance check-migration-reference lint-go all pass.

Noticed, not changed

  • A data view over a page parameter prints the parameter's name, -- Context: $currentObject (Order), rather than the qualified entity Shop.Order, although the source stores Shop.Order. That looks like the same class of issue, but changing it rewrites the most common context line on every page, so I left it for you to decide.
  • alter page … insert … (Attribute: NoSuchAttr) reports "Altered page", and the page then fails mx check with CE1613. That's a separate, pre-existing gap.

🤖 Generated with Claude Code

…its context (mendixlabs#1571)

`describe page` printed the association as the context entity of a data
container bound over an association:

  dataview dvInner (DataSource: $currentObject/Shop.Order_Customer) {
    -- Context: $currentObject (Shop.Order_Customer)   <- the association

dataSourceEntityContext used the datasource reference as the entity for every
kind but a flow. The reference means a different thing per kind: the entity for
a database source, the flow for a microflow/nanoflow source (fixed in
6e59e0e), the association for an association source. The page was always
correct; only the comment, and the association-name spelling that depends on the
context, was wrong.

The entity an association source reaches is stored on its last hop
(EntityRef.Steps[last].DestinationEntity), which is already right from either
end of the association, for a reference set, and for a specialization of the
association's end, so it is read instead of re-derived from the domain model.
associationSourcePath saw each step's destination but kept only the
association names; rawDataSource.Destination now carries the last one, set
where both association sources are built (Forms$AssociationSource / data view
and the pluggable XPath source). A source with no stored destination keeps the
reference, as the flow fix does. The `DataSource:` text is unchanged.

Tests: owner-to-child reference, the reverse direction, reference set with its
selection variable, specialization, two hops, a page-parameter start, the
pluggable source, the no-destination fallback, and database/flow controls.
Against upstream/main the association cases fail with the reported symptom.
Verified on a Mendix 11.12.5 project: both directions describe the entity,
describe -> exec reports "Unchanged page", mx check 0 errors.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

AI Code Review

Critical Issues

None found.

Moderate Issues

None found.

Minor Issues

None found.

What Looks Good

  • Thorough bug fix: Correctly addresses the core issue where association data sources showed the association entity instead of the destination entity in context comments.
  • Comprehensive test coverage: New test file covers all association source variants (data view, list view, gallery, data grid, pluggable sources) in both directions, reference sets, specialization cases, multi-hop paths, and fallbacks.
  • Real-world validation: Evidence includes manual verification on a Mendix scratch app showing corrected output, plus confirmation that mx check passes and round-trip describe→exec reports "Unchanged page".
  • Minimal, focused changes: Only touches the necessary files (rawDataSource struct, dataSourceEntityContext logic, two parser sites, and helper function) without over-engineering.
  • Proper fallback behavior: Maintains existing behavior when destination isn't stored (returns association reference), matching the flow source fix pattern.
  • Clean test organization: Uses table-driven tests with clear case names and helper functions for BSON construction.
  • Documentation: Includes CHANGELOG entry, bug findings file, and illustrative MDL example in mdl-examples/bug-tests/.
  • No syntax violations: Fixes behavior without modifying MDL grammar or syntax; adheres to existing CRUD verb patterns and qualified name usage.

Recommendation

Approve the PR. The change is correct, well-tested, and fully addresses issue #1571 while maintaining backward compatibility and following project conventions. No blocking issues identified.


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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

describe page: a data container over an association prints the association name as its context, not the entity it reaches

1 participant