Propagate column renames to FK and unique constraints in the table dialog (#9060)#10046
Propagate column renames to FK and unique constraints in the table dialog (#9060)#10046dpage wants to merge 1 commit into
Conversation
|
Warning Review limit reached
More reviews will be available in 7 minutes and 16 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
dpage
force-pushed
the
fix-9060-column-rename-fk-unique
branch
2 times, most recently
from
8c5f1c7 to
eb9f462
Compare
In the new-table dialog, the primary key already updated its column references when a column was renamed, but foreign key and unique constraint definitions did not, leaving them pointing at the old name. Mirror the PK rename-propagation in the foreign_key and unique_constraint depChange handlers (and add 'columns' to the unique constraint deps so it fires on column changes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dpage
force-pushed
the
fix-9060-column-rename-fk-unique
branch
from
eb9f462 to
c41ec7a
Compare
There was a problem hiding this comment.
Pull request overview
Fixes column-rename propagation in the Create Table dialog so constraint definitions don’t keep referencing stale column names (Issue #9060), preventing incorrect/broken generated DDL.
Changes:
- Propagate renamed column names into
foreign_key[].columns[].local_columnwhen editing table columns in the Create Table dialog. - Propagate renamed column names into
unique_constraint[].columns[].columnand ensure the unique-constraint handler is triggered on table column edits by addingcolumnstodeps. - Document the fix in the v9.16 release notes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| web/pgadmin/browser/server_groups/servers/databases/schemas/tables/static/js/table.ui.js | Adds rename-propagation logic for FK + unique constraints when a table column name changes. |
| docs/en_US/release_notes_9_16.rst | Adds a bug-fix entry referencing Issue #9060. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| return {unique_constraint: state.unique_constraint.map((uc)=>({ | ||
| ...uc, | ||
| columns: uc.columns?.map((c)=>( | ||
| c.column === oldName ? {...c, column: newName} : c | ||
| )), | ||
| }))}; |
| /* If a column is renamed, sync the foreign key local column references. #9060 */ | ||
| if(actionObj.type == SCHEMA_STATE_ACTIONS.SET_VALUE && actionObj.path[0] == 'columns' && | ||
| actionObj.path[actionObj.path.length-1] == 'name' && state.oid === undefined && | ||
| state.foreign_key?.length) { | ||
| let oldName = actionObj.oldState.columns[actionObj.path[1]]?.name, | ||
| newName = _.get(state, _.slice(actionObj.path, 0, -1))?.name; | ||
| if(oldName && newName && oldName !== newName) { | ||
| return {foreign_key: state.foreign_key.map((fk)=>({ | ||
| ...fk, | ||
| columns: fk.columns?.map((c)=>( | ||
| c.local_column === oldName ? {...c, local_column: newName} : c | ||
| )), | ||
| }))}; | ||
| } |
| Bug fixes | ||
| ********* | ||
|
|
||
| | `Issue #9060 <https://github.com/pgadmin-org/pgadmin4/issues/9060>`_ - Fixed an issue in the Create/Edit Table dialog where renaming a column did not update the column references in foreign key and unique constraint definitions for the new table. |
Summary
Fixes #9060.
In the Create Table dialog, renaming a column already propagated to the primary key definition, but foreign key and unique constraint definitions kept referencing the old column name — producing wrong/broken DDL.
Fix: mirror the existing PK rename-propagation logic in the
foreign_keyandunique_constraintdepChangehandlers — on a columnnameSET_VALUEin a new table, rewrite the old name to the new name in each FK'scolumns[].local_columnand each unique constraint'scolumns[].column. Also added'columns'to the unique constraint'sdepsso itsdepChangefires on column edits (FK already had it).Changes
table.ui.js(one file)🤖 Generated with Claude Code