pgapp assumes that pgapp:squery and pgapp:equery in the callback function in with_transaction must not contain PoolName if you want those queries to be executed inside the transaction. While this is appropriate in most cases, you may end up with unexpected behaviour when using multiple pool names in your app.
In these changes I aim for two goals:
You should be able to specify pool name inside the callback of with_transaction. The behaviour should be that if the pool name in squery or equery is not specified or equal to the one with_transaction was called with, it is considered as queries within the transaction. If the pool name is different, then those queries are working with another pool and are not within the transaction.
The last query (to pool2) is outside the transaction, but an error in the query still affects the transaction in pool1.
If nested calls of with_transaction with the same pool name take place, they should be ignored as postgres does not support nested transactions anyway.
While doing_stuff2 is a standalone function making queries in its own transaction, when being called in doing_stuff1 all the queries of both functions become a single transaction.
pgapp
assumes thatpgapp:squery
andpgapp:equery
in the callback function inwith_transaction
must not containPoolName
if you want those queries to be executed inside the transaction. While this is appropriate in most cases, you may end up with unexpected behaviour when using multiple pool names in your app.In these changes I aim for two goals:
You should be able to specify pool name inside the callback of
with_transaction
. The behaviour should be that if the pool name insquery
orequery
is not specified or equal to the onewith_transaction
was called with, it is considered as queries within the transaction. If the pool name is different, then those queries are working with another pool and are not within the transaction.Example:
The last query (to
pool2
) is outside the transaction, but an error in the query still affects the transaction inpool1
.If nested calls of
with_transaction
with the same pool name take place, they should be ignored as postgres does not support nested transactions anyway.Example:
While
doing_stuff2
is a standalone function making queries in its own transaction, when being called indoing_stuff1
all the queries of both functions become a single transaction.