-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: support inline-begin in mock server #1271
Conversation
partial.values.extend(row) | ||
partials.append(partial) | ||
partials[len(partials) - 1].stats = result.stats | ||
if started_transaction: | ||
partials[0].metadata.transaction = started_transaction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific reason we're including the transaction object details with the first partial result set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is how the Spanner API works:
- The first
PartialResultSet
in a stream should always contain the metadata for the query result. The remainingPartialResultSet
s will not have this field set. - If the request (e.g. the
ExecuteSqlRequest
) contained aBeginTransaction
option, then the metadata should also include the transaction ID of the transaction that was started as a side-effect of executing the request.
See https://cloud.google.com/spanner/docs/reference/rpc/google.spanner.v1#google.spanner.v1.TransactionSelector for a bit more background information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I just added a question for clarification on why we're including the transaction details with only a single partial result set
Adds support for inline-begin in the mock server.