Question

I am currently working on a new web application that needs to execute an SQL statement before giving a session to the application itself.

In detail: I am running a PostgreSQL database server with multiple schemas and I need to execute a SET search_path statement before the application uses the session. I am also using the ZopeTransactionExtension to have transactions automatically handled at the request level.

To ensure the exectuion of the SQL statement, there seem to be two possible ways:

Since I am using a scoped session and want to keep my transactions intact, I wonder which of these ways will possibly disturb transaction management.

For example, does the Engine hand out a new connection from the Pool on every query? Or is it attached to the session for its lifetime, i.e. until the request has been processed and the session & transaction are closed/committed?

On the other hand, since I am using a scoped session, can I perform it the way zzzeek suggested it in the second link? That is, is the context preserved and automatically reset once the transaction is over?

Is there possibly a third way that I am missing?

Was it helpful?

Solution

For example, does the Engine hand out a new connection from the Pool on every query?

only if you have autocommit=True, which should not be the case.

Or is it attached to the session for its lifetime, i.e. until the request has been processed and the session & transaction are closed/committed?

it's attached per transaction. But the "search_path" in Postgresql is per postgresql session (not to be confused with SQLAlchemy session) - its basically the lifespan of the connection itself.

The session (and the engine, and the pool) these days has a ton of event hooks you can grab onto in order to set up state like this. If you want to stick with the Session you can try after_begin.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top