-
Notifications
You must be signed in to change notification settings - Fork 43
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: add new_transaction support #499
Conversation
Hi Daniel, it looks like |
Yes, I believe it's intended to be off by default. Having it on or off may be more efficient depending on the circumstances, so we opted to keep it off by default (correct me if I'm misremembering @danieljbruce @bhshkh) |
This PR modifies the Transaction class to add a new
begin_later
argument.When True, the transaction will not initialize itself at the start of the context manager
__enter__
block. Instead, it will only begin at the first rpc. If the first rpc is a read call, this allows us to create the transaction at the same time as the call, saving a network call.This new behaviour is enabled by default, and is aligned with changes in other languages
For reviewers
In Python, a transaction is created in a context manager, and typically interacted with through the client (which passes through to the Transaction object when needed):
if begin_later is False, it will call
begin
automatically when entering that context manager block (using __enter__ method), retrieving a transaction_id from the server. Otherwise, begin is deferred until a get/query/commit call forces the transaction to talk to the backendStates
The state machine looks like this. Green lines denote transitions that are only valid when
begin_later=True
orange lines denote transitions that are valid whenbegin_later=False
begin
is called and the transaction receives and ID from the server, it moves into IN_PROGRESS statewith
statement)get
orquery
callbegin
manually