Fixed View/Edit Data not handling generated columns properly. #9672#9761
Fixed View/Edit Data not handling generated columns properly. #9672#9761RohitBhati8269 wants to merge 2 commits into
Conversation
WalkthroughExpose generated-column metadata, skip generated columns in INSERT/UPDATE payloads, optionally RETURN full updated rows for UPDATEs to refetch recalculated generated values, and refresh client grid for added or updated rows. ChangesData editor generated-column support
Sequence Diagram(s)sequenceDiagram
participant ComponentA
participant ComponentB
ComponentA->>ComponentB: observable interaction
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@web/pgadmin/tools/sqleditor/utils/save_changed_data.py`:
- Around line 173-183: The refetch logic must be guarded so we only enqueue a
refetch when the UPDATE can actually return identifiers: compute a boolean like
can_refetch_updated_row using command_obj.has_oids() or bool(pk_names) (pk_names
/ primary_keys are from command_obj.get_primary_keys()), and change the
condition that currently uses has_generated_cols alone to require both
has_generated_cols and can_refetch_updated_row before enqueuing the SELECT (the
place that later reads res['rows'][0]); this prevents attempting to read
returned rows when the UPDATE had no RETURNING clause.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: cdddcb83-6151-4d68-8a0e-6a6344e21f89
📒 Files selected for processing (5)
web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/columns/sql/12_plus/nodes.sqlweb/pgadmin/tools/sqleditor/static/js/components/sections/ResultSet.jsxweb/pgadmin/tools/sqleditor/templates/sqleditor/sql/default/update.sqlweb/pgadmin/tools/sqleditor/utils/get_column_types.pyweb/pgadmin/tools/sqleditor/utils/save_changed_data.py
✅ Files skipped from review due to trivial changes (1)
- web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/columns/sql/12_plus/nodes.sql
🚧 Files skipped from review as they are similar to previous changes (2)
- web/pgadmin/tools/sqleditor/static/js/components/sections/ResultSet.jsx
- web/pgadmin/tools/sqleditor/templates/sqleditor/sql/default/update.sql
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
web/pgadmin/tools/sqleditor/utils/save_changed_data.py (1)
185-210:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSkip UPDATE generation when no mutable columns remain.
After Line 187 filters generated columns,
datacan be empty. Renderingupdate.sqlthen produces an invalidUPDATE ... SET ...statement and fails the whole save operation. Add an early guard before rendering SQL.Proposed fix
# Remove generated columns (GENERATED ALWAYS AS) as they # cannot be updated - PostgreSQL auto-computes their values. data = {k: v for k, v in data.items() if not columns_info.get(k, {}).get('is_generated', False)} + + # Nothing left to update after filtering generated columns. + if not data: + continue pk_escaped = { pk: pk_val.replace('%', '%%') if hasattr( pk_val, 'replace') else pk_val🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/pgadmin/tools/sqleditor/utils/save_changed_data.py` around lines 185 - 210, After filtering out generated columns in save_changed_data.py the local variable data may be empty which causes render_template(... 'update.sql') to produce an invalid UPDATE; add an early guard after the generated-column filter that checks if not data and skips UPDATE generation—e.g., return/resolve as a no-op success or continue without calling render_template—so functions like render_template, update.sql and variables row_primary_keys, pk_escaped, has_generated_cols are not used when there are no mutable columns to persist.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@web/pgadmin/tools/sqleditor/utils/save_changed_data.py`:
- Around line 185-210: After filtering out generated columns in
save_changed_data.py the local variable data may be empty which causes
render_template(... 'update.sql') to produce an invalid UPDATE; add an early
guard after the generated-column filter that checks if not data and skips UPDATE
generation—e.g., return/resolve as a no-op success or continue without calling
render_template—so functions like render_template, update.sql and variables
row_primary_keys, pk_escaped, has_generated_cols are not used when there are no
mutable columns to persist.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f9652c5c-55b2-4956-bebc-c50c154ff5d1
📒 Files selected for processing (2)
web/pgadmin/tools/sqleditor/templates/sqleditor/sql/default/update.sqlweb/pgadmin/tools/sqleditor/utils/save_changed_data.py
Summary by CodeRabbit
New Features
Bug Fixes