Closed Dzeri96 closed 3 years ago
Hey @Dzeri96, that's a really tough one! I don't think there's any easy way for this because in the long run you would have to move away from getConnection()
and rather use this new approach for transactions.
Unfortunately, I don't think this library is the right fit for your codebase :disappointed:
You may be able to intercept the transaction using Node Async Hooks but I think this would be super difficult!
We don't have that many transactional functions, so switching to another approach would not be too difficult, provided it can somehow work with this library. Right now we have a hybrid approach, where tests which call such functions are run normally and then the whole DB gets rebuilt, which is not only slow, but it makes it hard to follow call chains to functions which might be transactional.
I'm open to any suggestions or workarounds to this problem. Also, make sure to review my PR!
Hey @Dzeri96 I've merged in your changes, let me know if you're happy with it :) I'd love to add some unit tests to that to make sure it works. Do you know how I can do that?
Hey, this issue is actually different from my PR in terms of functionality, so we can keep the discussion going there. As far as I know this one still hasn't been solved and I haven't looked into a solution yet.
So we have functions in the codebase that start a transaction block like so:
This obviously doesn't work with this package because the the innermost transaction just gets commited automatically. I know I could write a per-test scope in mocha with
describe
, and then write a localafter()
, but doing this requires me to know exactly what each test does, which is a big time sink when converting an entire test suite to a transactional one.Is there a way to intercept the innermost transaction and force it to revert in a generic way?