Skip to content

A to-one relation can be labelled, in English and per country - #7676

Open
nedelcho-delchev-tues wants to merge 2 commits into
eclipse-dirigible:masterfrom
nedelcho-delchev-tues:issue-7650-relation-label
Open

nedelcho-delchev-tues wants to merge 2 commits into
eclipse-dirigible:masterfrom
nedelcho-delchev-tues:issue-7650-relation-label

Conversation

@nedelcho-delchev-tues

Copy link
Copy Markdown
Contributor

Fixes #7650

A field could declare label: and countryLabels: (#6424), but the relation next to it could not — and a relation carries the model's identifier, so a company's Year.company rendered its picker, its list column and its details row as "Company" with no way to say "Issuing company" in the intent. The only place left for the English caption was the generated catalog, which the next Generate overwrites.

Both keys are now accepted on a to-one relation and on a subset. They are validated by exactly the rule a field's are — a blank label is refused, and a key that is no ISO 3166-1 alpha-2 country is refused because it could never match a tenant — and emitted onto the relation's own FK property as widgetLabel / widgetCountryLabels. That is the property every generated surface already reads its label from and the catalog is seeded from, so nothing downstream needed a change and an unlabelled relation generates byte-identically.

A oneToMany renders no control of its own (the FK lives on the child), so a label authored there would be carried nowhere. It is refused with a message that points at the construct that does render one, rather than silently dropped.

An n:m relation is expanded into its link entity before validation runs, so ManyToManyExpander moves the authored keys onto the to-target half of the link — the half the picker is rendered from.

Covered by FieldLabelIntentTest (the relation carries both keys, a collection is refused, a variant is held to the same country rule) and EdmFieldLabelTest (the caption reaches the FK property, an unlabelled relation carries nothing at all). The engine-intent suite is green: 1485 tests.

nedelcho-delchev-tues and others added 2 commits October 5, 2026 11:21
A field could declare `label:` and `countryLabels:` (eclipse-dirigible#6424) but the relation
next to it could not, and a relation is named for the model: `Year.company`
rendered its picker, its list column and its details row as "Company", with no
way to say "Issuing company" in the intent. The only place left to put the
English caption was the generated catalog, which the next Generate overwrites.

Both keys are now accepted on a to-one relation and on a `subset`, validated by
the same rule a field's are (a blank label is refused, a key that is no ISO
3166-1 country is refused because it could never match a tenant), and emitted
onto the relation's own FK property as `widgetLabel` / `widgetCountryLabels` -
the property every generated surface already reads its label from, so nothing
downstream changed. A `oneToMany` renders no control of its own, so a label
authored there would be carried nowhere and is refused rather than dropped.

An n:m is expanded before validation, so the authored keys travel with the
to-target half of the materialized link, where the picker ends up.

Fixes eclipse-dirigible#7650

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…on-label

# Conflicts:
#	.claude/docs/intent-dsl-features.md

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.

intent: label: is refused on a to-one relation - a picker's caption cannot be authored (VatGroundPick reads "Vat Ground Pick")

1 participant