Replies: 2 comments 1 reply
-
Hello @franky47 👋 Thank you for providing a detailed description of the issue and providing a reproduction. I would recommend opening a GitHub Issue so that our engineering team can have a look. Meanwhile, I'll go through the reported issue to check if I am able to reproduce this behaviour. |
Beta Was this translation helpful? Give feedback.
1 reply
-
I opened an issue for this problem: |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Question
I'm maintaining an extension that performs field-level encryption, by walking the tree of returned data to look for fields to decrypt.
Recently, I had a bug report indicating that it doesn't work with the Fluent API.
The heart of the problem is that the query passed to the extension asks for a type of data, but the data coming back after awaiting the downstream query doesn't correspond to that expected type (see 47ng/prisma-field-encryption#80 (comment)).
There doesn't seem to be a way for the extension to know that the downstream query will change the returned data type, as it seems to be done by the Prisma client when resolving SQL queries, and the type system won't help us here as this is a runtime issue.
Feel free to escalate this as an issue if it seems like something that's not expected. In the meantime, I'll mark my extension as not compatible with Fluent queries.
How to reproduce (optional)
See issue: 47ng/prisma-field-encryption#80
Expected behavior (optional)
The extension query parameters (in my case,
$allOperations
) are somehow passed some runtime information about the returned data type when running in a Fluent context, allowing extensions to adapt.Information about Prisma Schema, Client Queries and Environment (optional)
See issue: 47ng/prisma-field-encryption#80
Beta Was this translation helpful? Give feedback.
All reactions