Add full support for protocol.LAST_COMMIT_INFO (#45) #179
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alampe3ds
approved these changes
May 20, 2025
There was a problem hiding this comment.
LGTM. Seems to handle LastCommitInfo properly.
I don't really understand why threading issues need to be addressed now but not before. But that might be because I never used threading in python so far. So I give that part the benefit of doubt and assume you tested it properly.
madscientist
commented
May 20, 2025
madscientist
requested review from
pflynnnuodb
and removed request for
TheDistributor
|
@pflynnnuodb Martin is N/A this week so offering this to you for review. |
pflynnnuodb
approved these changes
May 21, 2025
pflynnnuodb
approved these changes
May 21, 2025
madscientist
force-pushed
the
pds/lastcommit
branch
from
522e542 to
0dcb97c
Compare
madscientist
force-pushed
the
pds/lastcommit
branch
from
0dcb97c to
27dcca2
Compare
Previously the LAST_COMMIT_INFO feature was only supported at the protocol level: the driver always reported there was no information available about the last commit. Last commit ensures "read your own writes" capability for committed transactions, even when connections are using different TEs. Implement an internal structure to store last commit information: - The information is saved as a process-wide set of data - Allows the same process to connect to different databases, and to connect to the same database multiple times (to the same or to different TEs). In order to support Python clients that may use threading with different connections, use a Lock() to access the last commit details. Python threading doesn't provide reader/writer locks; rather than write one we'll use a simple mutex and assume this won't be a performance bottleneck. Add a reset() method to forget all information about previously connected databases. This is not required since each database has its own UUID, but can free up resources for long-running applications that connect to lots of different databases.
madscientist
force-pushed
the
pds/lastcommit
branch
from
27dcca2 to
b6b90be
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously the LAST_COMMIT_INFO feature was only supported at the protocol level: the driver always reported there was no information available about the last commit.
Last commit ensures "read your own writes" capability for committed transactions, even when connections are using different TEs.
Implement an internal structure to store last commit information:
In order to support Python clients that may use threading with different connections, use a Lock() to access the last commit details. Python threading doesn't provide reader/writer locks; rather than write one we'll use a simple mutex and assume this won't be a performance bottleneck.