PostgreSQL 11.3 and 10.8

Re:PostgreSQL 11.3 and 10.8 by atombender on Thursday May 09, 2019 @02:21PM (#19870750)

Transactional tests have some downsides, unfortunately. If your tests test transactional code, that code itself cannot create transactions; they have to use savepoints, which aren't quite the same. Transactional tests also don't work with testing anything concurrent, unless you share the session across threads/goroutines/whatever.

Lastly, if a test fails you'd typically like to leave the data behind so that you can inspect it. A transactional test that rolls back on failure won't allow that.

[ Parent | on HN ]

Re:PostgreSQL 11.3 and 10.8 by munk-a on Thursday May 09, 2019 @02:53PM (#19871060)

Save points, with proper management of them, seem to match a conceptual nested transaction as far as I've seen. We've got a test bed connection manager that mocks savepoint creation, rollback and committal into transaction management functions so doing something like beginTransaction && beginTransaction works fine.

[ Parent | on HN ]

Re:PostgreSQL 11.3 and 10.8 by atombender on Thursday May 09, 2019 @03:01PM (#19871141)

There may be some semantic nuances. Savepoints aren't real transactions, so they "inherit" the locks of the parent transaction, for example. But it might not matter in practice in the context of tests.

[ Parent | on HN ]

Re:PostgreSQL 11.3 and 10.8 by Deimorz on Thursday May 09, 2019 @02:52PM (#19871041)

That's true, thanks. None of those are relevant for me, but there definitely are cases where it wouldn't be the right approach.

[ Parent | on HN ]