Drivine @Transactional() decorator breaks @UsePipes(new ValidationPipe)

[liberation-data]

Drivine @Transactional() decorator breaks @UsePipes(new ValidationPipe)

[jasperblues]

Workaround: Change the order that the decorators are applied.

[NilsMoller]

The order of the @Transactional decorator is important in other ways too it seems.
Using Nest's default GraphQL implementation, the following breaks:

// Transactional first, Query second
@Transactional()
@Query() 
async someQuery(): Promise<SomeModel> {
  // ...
}

However this works fine:

// Query first, Transactional second
@Query() 
@Transactional() 
async someQuery(): Promise<SomeModel> {
  // ...
}

[jasperblues]

@NilsMoller If you have time and able to submit some usage patterns you have with GraphQL, I would like to provide some guidance for that in the docs.

Meanwhile, for the txn decorator. One solution would be to more tightly integrate with Nest. Originally I created this decorator to not use anything from Nest, so it would be easy to port Drivine to use with eg AWS Lambda. But didn't get time to take that forward. Eg Nest's way would use reflect-metadata, and their interceptor hooks.

Or another solution is just trace why order is important, and workaround what's happening.