I am developing a server application using gorm—thank you for providing such a useful ORM tool. In production, we operate directly on the database itself, but in our testing environment, we utilize transactions (tx) to maintain test parallelism. This difference seems to be leading to the behavioral discrepancies as demonstrated in the tests.
Is this a bug, or is it an inevitable aspect of the nested transaction implementation? We observe that when a transaction is nested within another transaction (tx within tx), it behaves differently compared to when the parent context is the database connection itself.
We would expect the behavior to be consistent regardless of the parent context being a transaction or a direct database connection, to ensure reliability and predictability in both testing and production environments.
Explain your user case and expected results
I am developing a server application using gorm—thank you for providing such a useful ORM tool. In production, we operate directly on the database itself, but in our testing environment, we utilize transactions (tx) to maintain test parallelism. This difference seems to be leading to the behavioral discrepancies as demonstrated in the tests.
Is this a bug, or is it an inevitable aspect of the nested transaction implementation? We observe that when a transaction is nested within another transaction (tx within tx), it behaves differently compared to when the parent context is the database connection itself.
We would expect the behavior to be consistent regardless of the parent context being a transaction or a direct database connection, to ensure reliability and predictability in both testing and production environments.