-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transaction not rolling back as expected #46
Comments
Could you please clarify how do you create |
@Aliheym The import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { TaskEntity } from './task.entity';
@Injectable()
export class TaskService {
constructor(
@InjectRepository(TaskEntity)
private taskRepository: Repository<TaskEntity>,
) {}
} |
@sayinmehmet47 I made a test case with the same code as yours and it worked fine. What versions of Also, if you have a chance to create a minimal example with this behaviour, it would help a lot. |
Thank you for your patience, @Aliheym. I believe the confusion arose from the difference in the way the DataSource is initialized and added to the transactional context in the general example versus the NestJS specific example in the documentation. In the general example, the DataSource is created and then immediately initialized and added to the transactional context: const dataSource = new DataSource({
type: 'postgres',
host: 'localhost',
port: 5435,
username: 'postgres',
password: 'postgres'
});
initializeTransactionalContext({ storageDriver: StorageDriver.AUTO });
addTransactionalDataSource(dataSource); However, in the NestJS example, the DataSource is created and added to the transactional context within the dataSourceFactory function in the TypeOrmModule.forRootAsync method TypeOrmModule.forRootAsync({
useFactory() {
return {
type: 'postgres',
host: 'localhost',
port: 5435,
username: 'postgres',
password: 'postgres',
synchronize: true,
logging: false,
};
},
async dataSourceFactory(options) {
if (!options) {
throw new Error('Invalid options passed');
}
return addTransactionalDataSource(new DataSource(options));
},
}) This difference led me to initially try to initialize and add the DataSource to the transactional context directly after creating it, as shown in the general example. However, this approach did not work in my NestJS application. It was only after I followed the NestJS specific example and moved the initialization and addition of the DataSource to the transactional context into the dataSourceFactory function that my application worked as expected. I hope this clarifies the source of my confusion. I believe it would be helpful if the documentation could highlight this difference more clearly to guide other developers who might encounter the same issue. |
Thanks for your detailed explanation. Your point is clear and makes sense to me. I will improve the documentation. |
I am having a similar problem in a plain Node.js project. On the server.ts file, I initialize the TransactionalConext like this:
Where "AppDataSource" is imported from a class "ConnectionsManager" and represents the DataSource. This is the method I created with the annotation to test it:
The log 'Transaction rolled back' is being printed, but the entity is still being persisted in the DB. 2 transactions are being made, one that is committed and one that is rolled back 🧐 |
I have a method decorated with @transactional() where I'm trying to delete a non-existing record to force a transaction rollback. However, even though I see a log message indicating that the transaction has been rolled back, the changes made earlier in the transaction are not being rolled back in the database.
Expected behavior I expect that when an error is thrown in a transaction, all changes made in that transaction are rolled back.
To Reproduce Here's a simplified version of my code:
In this code, I'm updating a task and then trying to delete a non-existing task. When the delete operation doesn't find a task to delete, it should throw an error and the transaction should roll back, undoing the previous save operation. However, the save operation is not being rolled back.
The text was updated successfully, but these errors were encountered: