Protocol v1.0 - part 1 #3814
Merged
Protocol v1.0 - part 1 #3814
Conversation
This file contains 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
fantix
force-pushed
the
proto-v1
branch
2 times, most recently
from
975369e
to
df6f627
Compare
1st1
reviewed
May 2, 2022
There was a problem hiding this comment.
Dropping pre 0.13 looks OK.
As for copying the protocol - this is fine. I going to implement a different approach:
binary.pyx: EdgeConnection
binary_v0.pyx: EdgeConnectionBackwardsCompatible extends EdgeConnection
binary_v0.pyx would have v0 methods prefixed with def legacy_.
Then protocol.pyx could just always instantiate EdgeConnectionBackwardsCompatible
Now, I think your approach also works so let's go with it.
Thanks for the quick response! That's exactly what I wanted to know. However with my current approach, there're some complication of like switching the protocol object attached in the transport, and some in-and-out in the server. I'll try the inheritance approach very quickly and decide from there. |
fantix
force-pushed
the
proto-v1
branch
4 times, most recently
from
9b0339f
to
9997a4e
Compare
1st1
approved these changes
May 11, 2022
Also rename make_describe_msg to make_command_data_description_msg
The OptimisticExecute was not ready for the Parse/Execute convention because it was always looking up in the cache and ignoring the Parse result. This was an issue because some statement is not cacheable and compiling again confused the state machine (#3120). Fixed in a way that the previously parsed result is used if the query hash matches, and dropped immediately on _execute() to mimic the legacy OptimisticExecute behavior. test_server_proto_tx_03() and _04() covers both cases.
fantix
added a commit
that referenced
this pull request
Dec 6, 2023
The reason it was kept is explained in #3120, mitigated in #3814 #3837. But the core issue that compiler assumes mutation of transaction state for any compilation even by Parse message still exists. We can drop the `_last_anon_compiled` because the client bindings are no longer sending Parse + Execute for `commit` or `rollback` commands (which triggered two server compilation of the same command) like edgedb/edgedb-python#337. However, we still need to double check all bindings to make sure the transaction control commands are using only one `Execute` message.
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.
Pre-RFC: #3772
Depends on edgedb/edgedb-python#306