Skip to content
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

feat(spanner): support request and transaction tags #3233

Merged
merged 9 commits into from Apr 6, 2021

Conversation

olavloite
Copy link
Contributor

Adds support for request and transaction tags. This change depends on proto changes that have not yet been merged.

Adds support for request and transaction tags. This change depends on proto
changes that have not yet been merged.
@olavloite olavloite added the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Nov 19, 2020
@olavloite olavloite requested a review from a team as a code owner November 19, 2020 09:11
@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Nov 19, 2020
@tbpg tbpg changed the title feat: support request and transaction tags feat(spanner): support request and transaction tags Nov 19, 2020
@tbpg tbpg added the api: spanner Issues related to the Spanner API. label Nov 19, 2020
}
}

func checkRequestsForTags(t *testing.T, server InMemSpannerServer, reqCount int, qo QueryOptions) {
Copy link

@syeduguri syeduguri Nov 20, 2020

Choose a reason for hiding this comment

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

Better to rename it as "expectedQueryOptions".
Same comment for next function also.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think QueryOptions is the right name in this case, as QueryOptions also contain other options than tags, and those are not checked here. I think checkFor...RequestOptions would fit better here.

// The transaction tag to use for a read/write transaction.
// This tag is automatically included with each statement and the commit
// request of a read/write transaction.
TransactionTag string

Choose a reason for hiding this comment

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

Just wondering why there was empty TransactionOptions struct before this change.

Copy link
Contributor Author

@olavloite olavloite Nov 20, 2020

Choose a reason for hiding this comment

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

We had a major version bump recently, and added a number of breaking changes already back then that we knew would be needed for (among others) tagging support. Adding a struct is not breaking, but we also added a number of new methods that use this struct as a parameter. That way we don't need to have two major version bumps in a short period of time.

@@ -151,6 +160,10 @@ func (t *txReadOnly) ReadWithOptions(ctx context.Context, table string, keys Key
KeySet: kset,
ResumeToken: resumeToken,
Limit: int64(limit),
RequestOptions: &sppb.RequestOptions{
RequestTag: requestTag,
TransactionTag: t.qo.transactionTag,

Choose a reason for hiding this comment

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

We don't need transactionTag for readonly transactions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is true, but this method is used for both read-only and read/write transactions. The transactionTag field can however only be set for read/write transactions, so it will always be empty when this is used in combination with a read-only transaction.

Copy link

@syeduguri syeduguri left a comment

Choose a reason for hiding this comment

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

Looks like changes covered all APIs and scenarios. Just want to know where we handled PartitionedDML requests.
Left few minor comments.

@olavloite
Copy link
Contributor Author

Looks like changes covered all APIs and scenarios. Just want to know where we handled PartitionedDML requests.
Left few minor comments.

@syeduguri Thanks for the review.
Good point regarding PDML. That was missing but has been added now. PTAL.

@syeduguri
Copy link

Changes looks good to me.

}
}

func TestClient_Apply_Priority(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Apply_Tagging?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

RequestTag string
// transactionTag is unexported as applications should set this on the transaction and
// the transaction will then set this field for each request during the transaction.
transactionTag string
Copy link
Contributor

Choose a reason for hiding this comment

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

Why don't we put this to TransactionOptions? transactionTag seems to be more tight with a transaction instead of a query/update?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a reasonable question. I'll look into that to see whether that would be more reasonable once the proto changes have been merged. I tried to re-generate locally, but that seems to fail at the moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've removed the transactionTag from the QueryOptions as it was not a logical place to keep it.

@@ -874,6 +922,10 @@ func (t *ReadWriteTransaction) BatchUpdate(ctx context.Context, stmts []Statemen
Transaction: ts,
Statements: sppbStmts,
Seqno: atomic.AddInt64(&t.sequenceNumber, 1),
RequestOptions: &sppb.RequestOptions{
RequestTag: opts.RequestTag,
TransactionTag: t.qo.transactionTag,
Copy link
Contributor

Choose a reason for hiding this comment

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

What I mean is that we extract TransactionTag from t.txOpts (transaction options) instead of t.qo (query options)? Why do we need to keep transactionTag in QueryOptions? Just a thought.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, done (see also above).

@olavloite olavloite removed the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Apr 1, 2021
Copy link
Contributor

@hengfengli hengfengli left a comment

Choose a reason for hiding this comment

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

LGTM

@olavloite olavloite added the automerge Merge the pull request once unit tests and other checks pass. label Apr 6, 2021
@gcf-merge-on-green gcf-merge-on-green bot merged commit 2b416e8 into master Apr 6, 2021
@gcf-merge-on-green gcf-merge-on-green bot deleted the spanner-tagging branch April 6, 2021 07:54
@gcf-merge-on-green gcf-merge-on-green bot removed the automerge Merge the pull request once unit tests and other checks pass. label Apr 6, 2021
@skuruppu
Copy link
Contributor

skuruppu commented Apr 22, 2021

@olavloite unfortunately we have to roll this back since we are not able to release it yet as the backend is not ready for this. Hope you don't mind.

FYI @hengfengli

@olavloite
Copy link
Contributor Author

olavloite commented Apr 22, 2021

@olavloite unfortunately we have to roll this back since we are not able to release it yet as the backend is not ready for this. Hope you don't mind.

FYI @hengfengli

I'll prepare a revert. We probably also need to revert (or tweak) #3905 as well.

UPDATE: It seems that this PR cannot be (automatically) reverted because of other changes. I think that that is caused by the changes in #3905, which means that we need to revert that first. Then we can try to automatically revert this.

There's a revert PR for #3905 here: #3987

olavloite added a commit that referenced this pull request Apr 22, 2021
olavloite added a commit that referenced this pull request Apr 22, 2021
BREAKING CHANGE:
This removes the following exported functions and fields:
- TransactionTag(tag string) ApplyOption
- TransactionOptions.TransactionTag
- QueryOption.RequestTag
- ReadOption.RequestTag

This reverts commit 2b416e8.
hengfengli pushed a commit that referenced this pull request Apr 22, 2021
BREAKING CHANGE:
This removes the following exported functions and fields:
- TransactionTag(tag string) ApplyOption
- TransactionOptions.TransactionTag
- QueryOption.RequestTag
- ReadOption.RequestTag

This reverts commit 2b416e8.
olavloite added a commit that referenced this pull request Jun 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the Spanner API. cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants