TypeORM Transactions - Usar Transaction com vários repositórios
#Nestjs #typeorm
Olá comunidade, tempo atrás tive dificuldade para implementar Transaction usando o DataSource personalizado e cheguei na seguinte solução no momento, caso alguém tenha melhorias, ficarei grato ao compartilhar sua solução com a comunidade.
Supondo que eu tenha este serviço de exemplo:
Ao criar uma loja eu crie também um estoque e funcionários
connection.service
async configDataSource() {
// adicionar configurações do banco de dados
const connection = new DataSource({...});
return connection;
}
loja.service
export class MyService {
constructor(
private connection: ConnectionService
) {}
createLoja() {
// chama a função de antes e `initialize`
const datasource = await this.connection.configDataSource();
await datasource.initialize();
// A restrição mais importante ao trabalhar em uma transação é **SEMPRE** use a instância fornecida pelo gerente da entidade-`manager`
await datasource.transaction(async (manager) => {
try {
// usando `getRepository(Loja)`, poderá especificar qual entity irá ser usada naquele momento
await manager.getRepository(Loja).delete(...)
await manager.getRepository(Loja).save(...)
await manager.getRepository(Estoque).save(...)
await manager.getRepository(Funcionario).save(...)
} catch (err) {
return err;
}
});
}
}
Caso dê erro ao inserir um Funcionario, vamos reverter as alterações que fizemos antes. Fontes:
A questão a se perguntar ANTES de fazer um código que dê suporte a transações é: POR QUÊ você precisa de uma transação?! Aplicações modernas apelam para NoSQL exatamente porque NÃO precisam de transações. Ou melhor, as transações são implementadas de forma a não bloquear recursos nem sair desfazendo coisas caso algo dê errado no meio do caminho. Codificar sem depender de transações permite o uso de tecnologias infinitamente mais eficientes (e baratas!), mas claro exige muito mais cuidado na hora de planejar a aplicação. Por exemplo, meter loja (delete?!), estoque e funcionário na mesma transação COM CERTEZA demonstra a necessidade de refatorar a aplicação.