Our tables have PK sequences with different names than the ones postgres generates automatically. Because of that the lastInsertId() call inside haveInDatabase() generates a silent error.
When you use the method in a transaction, you don't see the actual error but the transaction is marked as "aborted" and you get exception and test fail on the next db statement. Without a transaction the test works fine but leaves other residues, which I hoped to clear by rollback. It took some time to debug and find the actual cause.
I did not find any warning about such limitation or previous mentions of it.
As a workaround I used INSERT .. RETURNING.
Our tables have PK sequences with different names than the ones postgres generates automatically. Because of that the lastInsertId() call inside haveInDatabase() generates a silent error.
When you use the method in a transaction, you don't see the actual error but the transaction is marked as "aborted" and you get exception and test fail on the next db statement. Without a transaction the test works fine but leaves other residues, which I hoped to clear by rollback. It took some time to debug and find the actual cause.
I did not find any warning about such limitation or previous mentions of it.
As a workaround I used INSERT .. RETURNING.