Add support for nesting @Transactional decorators

[kareemalkoul]

i use function used @Transactional inside this function calling to function using aleady @Transactional, so i noticed the parent @Transactional is ovveride dont use it so it is act like not @Transactional in parent function ex:

 @Transactional()
async parentfun(){

   await fun1()
   await fun2()
}

@Transactional()
async fun1(){

    //some operation from prisma

}

@Transactional()
async fun2(){

    //some operation from prisma

}

in the example above if some error happen in fun2 the operation in fun1 not rollback

[Papooch]

Yes, that is true. Currently, each @Transactional decorator creates a new transaction.

I have a plan to add nesting options soon, but for now it's a limitation of the library, so please stay tuned.

[Papooch]

I propose the following APIs for the propagation control, inspired by the Spring framework:

An enum called Propagation with possible values:

• Required - (default) Reuse the existing transaction or create a new one if none exists
• Mandatory - Reuse an existing transaction, throw an exception otherwise
• Never - Throw an exception if an existing transaction exists, otherwise create a new one
• NotSupported - Run the method without a transaction even if one exists (essentially calling TransactionHost#withoutTransaction)
• RequiresNew - Create a new transaction even if one already exists

Introducing the default behavior or Propagation.Required wold be a BREAKING CHANGE since the default (and only mode) is now Propagation.RequiresNew

And then use it in one of the following ways (TO BE DECIDED) to specify it:

1) Pass it as the first parameter to the @Transactional or withTransaction calls

@Transactional(Propagation.RequiresNew, { someAdapterOption: ... })
async doSomething(){
  // ...
}

async doSomething(){
  return this.txHost.withTransaction(Propagation.RequiresNew, { someAdapterOption: ... }, async () => {
    // ...
  })
}

2) ~Mix it into the adapter options~

• there's a risk of name collision if the adapter options contain a propagation property)

@Transactional({
  propagation: Propagation.RequiresNew,
  someAdapterOption: ...
})
async doSomething(){
  // ...
}

async doSomething(){
  return this.txHost.withTransaction({
    propagation: Propagation.RequiresNew,
    someAdapterOption: ... 
  }, async () => {
    // ...
  })
}

3) ~Move adapter options into a nested field instead~

• Unnecesarily verbose for most use-cases

  
  @Transactional({
  propagation: Propagation.RequiresNew,
  adapterOptions: { someAdapterOption: ... }
  })
  async doSomething(){
  // ...
  }

async doSomething(){ return this.txHost.withTransaction({ propagation: Propagation.RequiresNew, adapterOptions: { someAdapterOption: ... } }, async () => { // ... }) }

[Papooch]

@kareemalkoul An update with a support for propagation modes was just published, please update @nestjs-cls/transactional to v2 and your adapter to latest and see the new documentation.

npm i @nestjs-cls/transactional@latest @nestjs-cls/transactional-adapter-<youradapter>@latest