typeorm-trasactional-cls-hooked v0.1.1

typeorm-trasactional-cls-hooked

A Transactional Method Decorator for typeorm that uses cls-hooked to handle and propagate transactions between different repositories and service methods.

Inpired by Spring Trasnactional Annotation and Sequelize CLS

Installation

yarn add typeorm-trasactional-cls-hooked
## Needed dependencies
yarn add cls-hooked typeorm

Or

npm install --save typeorm-trasactional-cls-hooked
## Needed dependencies
npm install --save cls-hooked typeorm

Initialization

In order to use it, you will first need to initialize the cls-hooked namesapce before your application is started

import { initializeTransactionalContext } from 'typeorm-trasactional-cls-hooked';

initializeTransactionalContext() // Initialize cls-hooked
...
app = express()
...

BaseRepository

Since this is an external library, All your typeorm repositories, will need to be a custom repository extending the BaseRepsitory class.

// Post.entity.ts
@Entity()
export class Post{
  @PrimaryGeneratedColumn()
  id: number

  @Column
  message: string
  ...
}

// Post.repository.ts
import { EntityRepository } from 'typeorm';
import { BaseRepository } from 'typeorm-trasactional-cls-hooked';

@EntityRepository(Post)
export class PostRepository extends BaseRepository<Post> {}

Using Transactional Decorator

Every service method that needs to be transactional, need to use the Transactional Decorator The decorator can take a connectionName as argument (by default it is default) The decorator can take a propagation as argument defining the propgatation behavior

export class PostService {
  constructor(readonly repository: PostRepsitory)

  @Transactional() // Will open a transaction if not already exists
  async createPost(id, message): Promise<Post> {
    const post = this.repository.create({ id, message })
    return this.repository.save(post)
  }
}

Transaction Propagation

The following propagation options can be specified (as mentioned before, inspired by Spring Transactional):

• MANDATORY - Support a current transaction, throw an exception if none exists.
• NESTED - Execute within a nested transaction if a current transaction exists, behave like REQUIRED else.
• NEVER - Execute non-transactionally, throw an exception if a transaction exists.
• NOT_SUPPORTED - Execute non-transactionally, suspend the current transaction if one exists.
• REQUIRED (default behavior) - Support a current transaction, create a new one if none exists.
• REQUIRES_NEW - Create a new transaction, and suspend the current transaction if one exists.
• SUPPORTS - Support a current transaction, execute non-transactionally if none exists.