Skip to content

chore: replace RETURNING + fetch_one w/ execute + rows_affected#621

Open
chet wants to merge 1 commit intoNVIDIA:mainfrom
chet:rows_affected_not_returning
Open

chore: replace RETURNING + fetch_one w/ execute + rows_affected#621
chet wants to merge 1 commit intoNVIDIA:mainfrom
chet:rows_affected_not_returning

Conversation

@chet
Copy link
Contributor

@chet chet commented Mar 18, 2026

Description

This was an incidental observation from #609.

We have a number of cases where we are doing an UPDATE with RETURNING ..., and then chain .fetch_one() to make sure an update occurred, and never actually use the returned value. I think there was some elegance to this in the sense it was less code, but the downsides are:

  • The DB was serializing a return that we throw away.
  • We aren't expressing our actual intent -- do we want a row? Do we want multiple rows? Do we not care?

This is more lines of code, but clearly expresses our intent, doesn't discard values, and produces a clear NotFoundError.

FWIW this is probably debatable too. Maybe we'd prefer the other approach. Part of me likes it for the elegance, but I think it's part of the elegance that can leave you guessing (which is exactly why it was brought up in a code review to begin with).

Signed-off-by: Chet Nichols III chetn@nvidia.com

Type of Change

  • Add - New feature or capability
  • Change - Changes in existing functionality
  • Fix - Bug fixes
  • Remove - Removed features or deprecated functionality
  • Internal - Internal changes (refactoring, tests, docs, etc.)

Related Issues (Optional)

Breaking Changes

  • This PR contains breaking changes

Testing

  • Unit tests added/updated
  • Integration tests added/updated
  • Manual testing performed
  • No testing required (docs, internal refactor, etc.)

Additional Notes

…iscarded results

This was an incidental finding from NVIDIA#609.

Basically we have a number of cases where we are doing an `UPDATE` with `RETURNING ...`, and then chain `.fetch_one()` to make sure an update occurred, and never actually use the returned value. No need for this. Instead, we can drop `RETURNING ...` and just chain `.rows_affected()`.

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
@chet chet requested a review from a team as a code owner March 18, 2026 18:23
@github-actions
Copy link

🔐 TruffleHog Secret Scan

No secrets or credentials found!

Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉

🔗 View scan details

🕐 Last updated: 2026-03-18 18:24:08 UTC | Commit: 3625e66

@github-actions
Copy link

🛡️ Vulnerability Scan

🚨 Found 72 vulnerability(ies)
📊 vs main: 72 (no change)

Severity Breakdown:

  • 🔴 Critical/High: 72
  • 🟡 Medium: 0
  • 🔵 Low/Info: 0

🔗 View full details in Security tab

🕐 Last updated: 2026-03-18 18:24:16 UTC | Commit: 3625e66

@chet chet changed the title chore: replace RETURNING + fetch_one w/ execute + rows_affected for discarded results chore: replace RETURNING + fetch_one w/ execute + rows_affected Mar 18, 2026
Copy link
Collaborator

@ajf ajf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the if statement pretty much unreadable imho since the conditional is on some row a bunch of lines down and hard to read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants