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
Conversation
Adds support for request and transaction tags. This change depends on proto changes that have not yet been merged.
spanner/client_test.go
Outdated
} | ||
} | ||
|
||
func checkRequestsForTags(t *testing.T, server InMemSpannerServer, reqCount int, qo QueryOptions) { |
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.
Better to rename it as "expectedQueryOptions".
Same comment for next function also.
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.
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 |
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.
Just wondering why there was empty TransactionOptions struct before this change.
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.
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.
spanner/transaction.go
Outdated
@@ -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, |
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.
We don't need transactionTag for readonly transactions.
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.
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.
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.
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. |
Changes looks good to me. |
spanner/client_test.go
Outdated
} | ||
} | ||
|
||
func TestClient_Apply_Priority(t *testing.T) { |
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.
Apply_Tagging
?
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.
Done
spanner/transaction.go
Outdated
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 |
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.
Why don't we put this to TransactionOptions
? transactionTag
seems to be more tight with a transaction instead of a query/update?
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.
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.
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.
I've removed the transactionTag
from the QueryOptions
as it was not a logical place to keep it.
spanner/transaction.go
Outdated
@@ -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, |
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.
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.
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.
Good point, done (see also above).
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
@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. |
This reverts commit 2b416e8.
BREAKING CHANGE: This removes the following exported functions and fields: - TransactionTag(tag string) ApplyOption - TransactionOptions.TransactionTag - QueryOption.RequestTag - ReadOption.RequestTag This reverts commit 2b416e8.
BREAKING CHANGE: This removes the following exported functions and fields: - TransactionTag(tag string) ApplyOption - TransactionOptions.TransactionTag - QueryOption.RequestTag - ReadOption.RequestTag This reverts commit 2b416e8.
Adds support for request and transaction tags. This change depends on proto changes that have not yet been merged.