Skip to content

Widen SingleStoreBulkUpdateResult row counts to long - #29

Open
okramarenko wants to merge 1 commit into
masterfrom
changesforPR28
Open

okramarenko wants to merge 1 commit into
masterfrom
changesforPR28

Conversation

@okramarenko

Copy link
Copy Markdown
Collaborator

This PR is an extension to the PR #28.

@cursor

cursor Bot commented Oct 27, 2026 •

Copy link
Copy Markdown

PR Summary

Medium Risk
Breaking public API on an experimental type and a behavioral change in how affected rows are read for the UPDATE phase; logic is localized to bulk update but callers assigning to int will need updates.

Overview
Breaking change to the experimental bulk-update API: SingleStoreBulkUpdateResult.RowsMatched is now long? and RowsAffected is now long, so match and affected counts above int.MaxValue are reported exactly instead of overflowing or being clamped.

Implementation follows that contract: the optional match COUNT(*) uses Convert.ToInt64, and the UPDATE phase reads SingleStoreDataReader.RealRecordsAffected after fully consuming the reader (instead of ExecuteNonQuery, which caps at int.MaxValue). Bulk-update logging and release notes/tutorial text are updated accordingly; RowsStaged stays int (client-side staging count).

Reviewed by Cursor Bugbot for commit 41d70cf. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Approved. Cursor Bugbot completed successfully with no findings that need human review, and Cursor Security Agent was not present so that signal was skipped. No approval policy required additional review.

Open in Web View Automation 

Sent by Cursor Approval Agent: Pull Request Router and Approver

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant