`@Transactions` decorator, Expose and accept a transaction object

Problem

We cannot use a @Transaction decorator or access the transaction object and pass it directly to the query itself.

Suggested solution

Any thought on doing this: Returning $transaction to the user and pass it to the API interface as a argument. Something like this:

const transactionObj = prisma.createTransaction();
const user = await prisma.user.create({
  data: {
    email: '[e-mail]',
    name: 'Elsa Prisma',
  },
  { transactions: transactionObj }
})
const temp = prisma.temp.update({ where: { id: 1}, data: {f1: 1},  { transactions: transactionObj }})

TBH I do not like this approach too much (Passing extra stuff, too noisy and annoying)

Alternatives

AFAIK nothing except those listed in the doc which is not practical in most cases.

[adrian-goe]

please have a look at https://github.com/prisma/prisma/issues/12975, that discusses the same topic. And also have a look at https://github.com/prisma/prisma/issues/12458

The problems discussed in https://github.com/prisma/prisma/issues/12458 regarding the test situation would also be solved with a @Transactional annotation.

As said in my other comments in the other issues, this is more or less a standart in the Spring Hibernate world.

[cesarvspr]

Can you elaborate how the current functionality of interactiveTransactions does not fit your use case? The example in your initial message would be triviial to support with this - but I assume you out some of the complexity for the feature request.

I think OP and me are talking about Prisma providing a @transaction decorator which would provide a transaction for the functions execute below. I don’t have expertise to say if this is difficult to implement.

Of course, this is not blocking, the actual $transaction works pretty well.

But a decorator would provide more readability for the code.