fix(#1532): diagram edge weight encodes cardinality, not master-part - #1533
Open
dimitri-yatsenko wants to merge 1 commit into
Open
fix(#1532): diagram edge weight encodes cardinality, not master-part#1533dimitri-yatsenko wants to merge 1 commit into
dimitri-yatsenko wants to merge 1 commit into
Conversation
Line weight is binary and encodes cardinality only: thick when the foreign key constitutes the child's entire primary key (1:1), thin when the child has primary-key attributes beyond those the FK contributes (multi-valued) — newly declared or inherited from another FK. penwidth already followed this via multi; remove the misleading master-part conflation in the layout weight and drive it from the same predicate so the two never diverge. Rename-safe: multi compares the child's referencing columns to the child primary key (both child-column space), so a renamed FK that is the child's whole PK is correctly 1:1/thick. Adds a guardrail test (1:1, multi, master-part, renamed-1:1).
dimitri-yatsenko
added
the
bug
dimitri-yatsenko
marked this pull request as ready for review
August 10, 2026 21:41
Member
Author
|
@ttngu207 @MilagrosMarin — part of the diagram-notation set (#1533 edge-weight → #1534 restyle → #1536 no-context fix). New style shown on a real pipeline: https://github.com/datajoint/lcms-demo/tree/viz/diagram-restyle-1534 (datajoint/lcms-demo#3). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 1 of #1532 — the correctness fix (not style). The style restyle (palette, entity groups, direction, renamed-edge color) will follow as a separate PR.
The rule
Line weight is binary and encodes cardinality only:
penwidth 2) — the foreign key constitutes the child's entire primary key → 1:1.penwidth 0.75) — the child has primary-key attributes beyond those the FK contributes (newly declared, or inherited from another FK) → multi-valued.The visible
penwidthalready followed this (via themultiedge flag). This PR removes the misleading master-part conflation in the layoutweighthint (set_weight(3 if master_part else 1)) — master-part is not a weight; a part almost always adds a key attribute, so its edge is thin under the same rule — and drivesweightfrom the same predicate so the two never diverge.Rename-safe
multi = set(FK child-columns) != set(child PK)compares in child-column space, so a renamed FK that is the child's whole primary key is correctly 1:1/thick. (The parent-PK-vs-child-PK name comparison sketched in the issue would break under renaming; this does not.)Test
tests/integration/test_diagram_edge_weight.pyrenders a diagram and assertspenwidthfor four cases: 1:1 (thick), multi-valued (thin), master→part (thin), and renamed-1:1 (thick). Green on MySQL 8.0 and PostgreSQL 15.Docs companion: datajoint/datajoint-docs#247.