API for interactive transactions with dependencies between write-operations
See original GitHub issueThere already is a GitHub issue asking for a way to submit multiple mutations within the same HTTP request where all mutations are executed as one transaction.
However, this feature does not allow for creating a transaction where the mutations depend on each other. Here is an example where the second operation depends on the first:
prisma.transaction(async tx => {
const user = await tx.createUser({
name,
})
// compute some stuff
await tx.updateOrder(user.id)
await tx.commit()
})
This is currently not possible with the Prisma API as it would require having a long-running connection where the results of the operations are sent back and forth between Prisma and the database.
It should be considered whether it is helpful to add such an API to Prisma, or whether abstractions like nested mutations and the requested transactional execution of multiple independent transactions are the better approach for Prisma.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:195
- Comments:122 (43 by maintainers)
Hi everyone,
We heard you loud and clear: most of you want to have that flexibility to choose when to use LRT and when not to, without being left with no other alternative than going through an entirely separate client or solution.
As mentioned earlier in this thread a while back, we do indeed want to give the ability to use long-running transactions in cases where they’re not a genuine concern or people do not have the choice to do otherwise (e.g. incrementally porting existing applications without rethinking their entire logic). This wasn’t prioritized so far as we wanted to make good strides on the topics at the forefront of our roadmap, specifically with our upcoming MongoDB connector, which is taking us a lot of effort right now.
We are starting the design work required to enable long-running transactions with Prisma Client, and greatly appreciate the suggestions put forward in this thread. At the same time, we recognize that many use cases are better solved using other approaches, and we will continue to invest heavily in Prisma Client to make sure you can do most of your work without having to resort to long-running transactions.
We will keep you posted with design proposals for that as we progress, and you should expect to see movement before or during summer on the topic.
Thanks for continuing to share your use cases, and staying constructive in your feedback, this greatly helps us improving Prisma!
Heads-up: We have internal prototypes running and we’re aiming for a preview release in 2.29, if no major blockers are uncovered along the way.