Fixed an issue where unique/primary key constraint columns were shown in wrong order in Properties#9635
Open
balodis wants to merge 1 commit intopgadmin-org:masterfrom
Open
Conversation
|
No actionable comments were generated in the recent review. 🎉 WalkthroughThis PR preserves backend-provided column order in the primary key and unique constraint UI formatters by mapping backend entries directly to option objects in Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The fromRaw formatter for the Columns field in unique constraint and primary key properties used _.filter(allOptions, ...), which preserved the order of allOptions (table column position) rather than the constraint-defined column order from backendVal. Replaced with _.find mapped over backendVal to preserve the correct constraint column order. Added unit tests for cell and type formatter functions to verify column ordering is preserved.
5d9012a to
ae4b146
Compare
adityatoshniwal
approved these changes
Feb 18, 2026
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
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.
Bug
When viewing a unique constraint or primary key in the Properties tab,
the Columns field shows columns in table-definition order instead of
the actual constraint-defined column order. For example, a constraint
UNIQUE (user_id, client_order_id)displays asclient_order_id, user_id.The SQL tab shows the correct order; only the Properties tab is wrong.
Root Cause
The
fromRawformatter inunique_constraint.ui.jsandprimary_key.ui.jsused_.filter(allOptions, ...), which iteratesover
allOptions(table columns) and keeps matches -- preservingallOptionsorder rather thanbackendValorder. The backend SQLand Python code correctly return columns in constraint-defined order.
Fix
Replaced
_.filter(allOptions, ...)with a.map(... _.find(...))over
backendVal, preserving the constraint column order from the backend.Tests
Added 6 new Jest tests (3 per file) covering:
fromRawverifying constraint column order is preservedtoRawround-trip correctnessAll 18 tests pass. ESLint clean.
Related
Related: #6345 (similar column ordering issue for foreign keys, fixed
separately in 7.3). This PR addresses the same class of bug in the
unique constraint and primary key Properties view.
Summary by CodeRabbit
Bug Fixes
Tests