-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Keep track of transaction information #35
Conversation
Since we have a reference to the connection, we could also not rely on Knex's transaction ID at all. Your call @felixmosh. I can sent the change if you want. |
This also solves #32, but only when running inside transactions. We could have a transaction with ID |
The new test If any of the |
@Fryuni I've really this like this approach, and the implementation! |
Again, thank you for this awesome contribution 🙏🏼 It released at |
Closes #34
This PR adds support for testing the relation of queries and transactions.
Edit: Transaction stack is managed independently of Knee internal state since it is not exposed.
First iteration:
Knex automatically generates a new unique ID for each transaction, passed on the
__knexTxId
of the connection.Each nested transaction receives a separate ID, with no relation to its parent. So this PR changes the inline connection object returned by the
acquireConnection
to a newMockConnection
class that keeps track of the transaction stack to properly support nested transactions. Documented hereSadly, Knex does not revert this ID once a transaction is over as, so far, this is not necessary for any of their driver implementations. As a workaround, we pass the connection down to the tracker, allowing it to walk up the transaction stack when a transaction is completed. Documented here
Also, the transaction ID generated by Knex is globally unique within a process, depending on a global state within one of its dependencies. This makes the ID impractical for tests since they are no predictable. To handle this, the transaction ID from Knex is replaced with a sequential numeric ID that is restarted when resetting the tracker. Documented here