-
Notifications
You must be signed in to change notification settings - Fork 216
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
Different txIf context when called from a transaction #479
Comments
No. Every task and transaction create their own connection context object with the protocol. And the default logic for method txIf is to create a new task when already in transaction. Your list of arguments isn't really valid...
Nothing stops you from doing so.
It is by design that you cannot use task/tx context outside of the callback. Also, creating the new context for each task/tx is what makes it possible to do independent extension of the protocol and/or implementation logic.
You still can do so, just not for nested context. |
@vitaly-t With the above example... db.tx('my-out-side-tx', function *(t2) {
sinonSandbox.spy(t2, 'none');
yield t2.DBRepo.action();
expect(t2.none).to.be.calledOnce;
}); This test failed, as we spy This is blocking us to write unit tests for transactions related code. |
And where is the This code doesn't have it. And from the look of it, the example should work - db.tx('my-out-side-tx', function *(t2) {
sinonSandbox.spy(t2, 'none');
yield t2.DBRepo.action();
expect(t2.none).to.be.calledOnce;
}); because this is no other task/tx context created there. |
@vitaly-t If you notice the code int he issue description, you will find |
Following this discussion, plus outside in Slack, opened new issue #480 as an improvement. |
The documentation for
txIf
refers that:The phrase to start a transaction only if currently not in transaction provide impression that it will use the same transaction if called within a transaction context. Which is actually not the case.
Take this as example:
So if we use it with the following code:
So logically
t1
andt2
should refer to same transaction, but it actually not the case.Its useful in many cases including:
We have many unit tests written for transaction related database repos, all of these start failing after upgrading to
txIf
. Please upgrade/fix thetxIf
with in context or suggest some way to unit test transactions with spying/stubbing.The text was updated successfully, but these errors were encountered: