You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some situations it is desirable that a write operation being committed is dependant on other write operations succeeding, for example, if you update 200 users within a transaction, each update must succeed - if not, all changes are rolled back and the transaction fails as a whole.
Suggested solution
We cannot support the same syntax that prisma does as we need to support a synchronous API as well
This is a good solution as it can easily be modified to support dependencies between write operations if it is added to the prisma query engine, #1844.
The only potential problem with this solution is that we are creating a new client reference which would potential be difficult for some users to implement but I cannot think of a way to do this while maintaining type safety.
As we have to type every action to return None there will be some refactoring to support it, but it should be possible with generics and if not we can always duplicate the whole client/actions classes with Jinja
The text was updated successfully, but these errors were encountered:
Query batching is only used when you want to send a lot of queries at once without having access to the returned objects between calls, e.g. if you're moving data from a JSON file to a Prisma model.
I've updated the original comment examples to illustrate the actual implemented API.
Problem
In some situations it is desirable that a write operation being committed is dependant on other write operations succeeding, for example, if you update 200 users within a transaction, each update must succeed - if not, all changes are rolled back and the transaction fails as a whole.
Suggested solution
This is a good solution as it can easily be modified to support dependencies between write operations if it is added to the prisma query engine, #1844.
The only potential problem with this solution is that we are creating a new client reference which would potential be difficult for some users to implement but I cannot think of a way to do this while maintaining type safety.
async
sync
Additional context
Implementation notes
As we have to type every action to return None there will be some refactoring to support it, but it should be possible with generics and if not we can always duplicate the whole client/actions classes with Jinja
The text was updated successfully, but these errors were encountered: