feat(er-diagram): lay tables out in compact 2D clusters with color#1757
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c0e6077387
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let totalArea = blockSizes.reduce(0) { $0 + $1.width * $1.height } | ||
| let widest = blockSizes.map(\.width).max() ?? 0 | ||
| let targetWidth = max(widest, sqrt(totalArea * 1.6)) | ||
| let order = blockSizes.indices.sorted { blockSizes[$0].height > blockSizes[$1].height } |
There was a problem hiding this comment.
When a schema has many unrelated tables plus a small FK component, the unrelated-table grid is usually the tallest block, so this height sort places it at (0,0) and shelves the connected component below it. That contradicts the new layout behavior documented in docs/features/er-diagram.mdx:25 that tables with no relationships sit at the bottom, and it makes the main relationship diagram start underneath unrelated noise. Keep the singleton grid out of this height-based ordering or force it to be packed after connected components.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1614e2bee2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ) { | ||
| let count = members.count | ||
| let padding = horizontalGap * 0.5 | ||
| let passes = max(20, min(count, 60)) |
There was a problem hiding this comment.
For dense relationship components (for example, a few dozen tables with several FKs per table), this fixed pass limit can exit while table rectangles still intersect; there is no validation after removeOverlaps, so makeBlock and the Canvas render those tables on top of each other. Please keep resolving until there are no collisions, or fall back to a grid/packing strategy when the limit is reached.
Useful? React with 👍 / 👎.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
datlechin
deleted the
emdash/feat-er-diagram-layout-problem-database-1335-s1ntm
branch
1 participant
Closes #1755 (related #1335)
Problem
The ER diagram used a Sugiyama layered layout that ranked tables into horizontal rows by foreign-key depth, then centered every row inside the combined width of all nodes. Shallow, cyclic schemas collapsed into a few very wide rows stacked vertically, so large diagrams were tall, narrow, and wasted horizontal space.
Change
Replaced the layered engine with a component-aware compact layout, and reused the connected-component pass to color clusters.
ERDiagramLayout.computekeeps its signature (graph -> [UUID: CGPoint]), so the ViewModel, persistence, and re-layout paths are unchanged.Tests
The graph/layout pipeline had no coverage. Added:
ERClusterAnalyzerTests: chain, star, two components, isolated tables, self-loop, mixed, determinism, empty.ERDiagramLayoutTests: every node positioned, no box overlap, components in disjoint regions, deterministic re-run, isolated tables fill horizontal space, empty/single graph.Notes
docs/features/er-diagram.mdx) andCHANGELOG.mdupdated.swiftlint lint --strictclean on all changed files. Build/run not done locally (Xcode build is the maintainer's step).