fix(client): bind itx to correct client when extensions are used #19565
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
SevInf
force-pushed
the
fix/itx-extensions
branch
2 times, most recently
from
46a4036
to
f0936db
Compare
SevInf
commented
Jun 2, 2023
millsp
reviewed
Jun 2, 2023
millsp
approved these changes
Jun 2, 2023
|
Note: Snapshots need updates |
SevInf
force-pushed
the
fix/itx-extensions
branch
from
198a582
to
f0dbd9d
Compare
SevInf
added a commit
that referenced
this pull request
Jun 14, 2023
In #19565 we had to change how iTx client calls it's methods. Previously, it was calling them on default client and appending transaction information afterwards. After that change, it started calling them on iTxClient. Unitended consequence of that: now every cleint property is proxied, including private properties, private properties of nested object, returned results, etc. It breaks in a situation like #19653 and #19685. This PR attempts to rework how itxProxy works. The only thing we need from itxProxy is ability to pass transaction paramters to the queries within the callback. Here, it is achieved by introducing a factory for PrismaPromises that is bound to a specific client instance. When used on default transaction, factory creates normal promise. ITX client replaces the default factory with the one that always produces promises, bound to a specific transaction. So, instead of deeply proxying everything on itxClient, it creation is now this: - replace promise factory with the one that is bound to a transaction - remove denylist properties - add TX_ID property This is better and safer solution to #19565, as well as code simplification. Unblocks #19685
SevInf
added a commit
that referenced
this pull request
Jun 14, 2023
In #19565 we had to change how iTx client calls it's methods. Previously, it was calling them on default client and appending transaction information afterwards. After that change, it started calling them on iTxClient. Unitended consequence of that: now every cleint property is proxied, including private properties, private properties of nested object, returned results, etc. It breaks in a situation like #19653 and #19685. This PR attempts to rework how itxProxy works. The only thing we need from itxProxy is ability to pass transaction paramters to the queries within the callback. Here, it is achieved by introducing a factory for PrismaPromises that is bound to a specific client instance. When used on default transaction, factory creates normal promise. ITX client replaces the default factory with the one that always produces promises, bound to a specific transaction. So, instead of deeply proxying everything on itxClient, it creation is now this: - replace promise factory with the one that is bound to a transaction - remove denylist properties - add TX_ID property This is better and safer solution to #19565, as well as code simplification. Unblocks #19685
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, when extension callback was called,
thiswithin was bound to original client, nottransactionProxy. This is relatively easy to fix by preservingthiscontext of the function in which it was called.Consequence of this change: methods, that are not available on ITX client are now optional within the client extensions. Type change was necessary due to runtime behavior change: since extension context can now be bound to either ITX or normal client, there is no guarantee that those methods would exist.
Related fix: on a type elvel
ITXClientwas not receivingclientcomponents of the extension correctly. Fixed that as well.