fix(data): model convert silently drops relationships and picklist columns

[david-hudec-networg]

Two defects in DataModelConverter. Both are silent: output stays well-formed while losing model content, so nothing surfaces until you diff against the source declarations. Found while building a layered ERD across a product base and three customer solutions.

1. N:1 relationships deduped on the table pair, not the column

DataModelConverterService.cs:492 compares only LeftSideTable and RighSideTable, so every relationship after the first between the same pair is dropped.

talxis_project has four separate lookups to account — building authority, city, city district, architectural studio. One edge was emitted. All four columns still rendered, because columns are emitted separately from relationships, so the diagram understated the model without looking broken.

Fix: include LeftSideRow in the key. Table.GetOrCreateRow caches by name, so two relationships through the same column share one TableRow instance and reference equality holds. That is also what dbdiagram constrains — the endpoint pair, not the table pair — so genuinely duplicated declarations still collapse, which is presumably why the guard exists.

2. A picklist column is deleted when its option set will not resolve

The filter at :366 removes Picklist/Multiselectoptionset/State/Status/Bit rows whose OptionSetName is not among the resolved option sets. Three triggers observed:

• the global option set file exists but declares <options />
• the option set is declared in a different module from the attribute using it
• the option set is platform-owned (activitypointer_*, socialprofile_*) with no file in the repo

Required, form-visible business columns disappear with no warning, and a module whose only contribution is such an attribute reads as a non-contributor.

Fix: clear OptionSetName instead of deleting the row. That is the minimum the problem needs — ToDbDiagramNotation prefers OptionSetName over RowType, so a stale name would reference an Enum that was never emitted. RowType is deliberately left alone so each translator keeps its own handling: sql falls back to its existing nvarchar(255) for an unresolvable picklist, edmx keeps Edm.Boolean for a bit, and dbml renders the bare kind. An earlier revision of this PR also forced RowType.Int; that reached past DBML into every target sharing ParseModules and imposed a DBML-driven choice on sql and edmx, so it was reverted.

Measured

Built from source, baseline vs patched, on three real declaration folders:

folder	refs	columns
customer Model layer	9 → 14	214 → 215
Service/Project/Model	87 → 99	914 → 918
Environment/Bootstrap/Model	87 → 100	1344 → 1349

Table and Enum counts unchanged in all three. No duplicate endpoint pairs introduced. No column left typed as an undeclared Enum. All three targets (dbml, sql, edmx) exercised.

Notes

• Two changed sites, no refactoring, no new types.
• The many-to-many path (:439-455) is untouched and correct for the non-self-referential case. A separate defect exists there — a self-referencing N:N emits the intersect column twice and the Ref: line twice — which this PR does not address.
• Tests: not included. DataModelConvertTests.cs is entirely [Fact(Skip = ...)] integration tests needing a real solution on disk. ParseModules is public static and both defects are unit-testable from in-memory XDocument fixtures; happy to add them wherever you would want them, but I did not want to guess at placement in a draft.
• Two further issues in the same area are not in this PR: table colours are randomised per run (Module seeds Colorhex from new Random(), so the same unchanged solution converts to a different file every time), and the synthesised <entity>id primary key is wrong for activity entities — the latter is not fixable here, since the only layer that triggers key synthesis is also the layer that omits IsActivity.

🤖 Generated with Claude Code