Is it safe, from within either the 'before_execute' or 'before_cursor_execute' events, to use the same connection to execute a SQL statement before the current one? I assume there is a good chance the answer is no, at least for before_cursor_execute.
Why? I only want to issue the SQL to update the database's session variables if needed. Most connection checkout-checkin life cycles will only ever issue SELECT statements and so don't need the database session updated for auditing, so I was intending on waiting until I actually know it is needed (from within before_cursor_execute) before issuing the DBMS_SESSION.SET_CONTEXT(...). But, once I know that within before_cursor_execute, can I (recursively) issue an conn.execute() for that statement safely or will it affect the original execute? On Saturday, March 7, 2015 at 6:38:08 PM UTC-5, Michael Bayer wrote: > > > > Kent <jkent...@gmail.com <javascript:>> wrote: > > > I'm implementing database session variables (in Oracle, > DBMS_SESSION.SET_CONTEXT(...)), in order to be able to set (from > sqlalchemy) and retrieve (from a database trigger) the application userid > and URL path during table audit triggers. > > > > The tricky bit is that if I set the user to 'user1', that remains in the > session in the database even when a different sqlalchemy thread grabs that > same session from the connection pool. I want to prevent the wrong > information accidentally still being in the session, so I want to be sure > to reset it when appropriate and I'm wondering whether checkout from the > Pool is the event you would recommend? > > > > @event.listens_for(engine, 'checkout') > > def receive_checkout(dbapi_connection, connection_record, > connection_proxy): > > > > If the same database session is recycled from the connection pool, will > it have the same connection_record? I'd prefer to record the fact that > I've set the database session's variables on an object (such as > connection_record) so that subsequent requests can detect whether it needs > to be reset. Will connection_record correspond to a database session? > > > For this kind of thing you normally reset the state on the “checkin” > event. > The connection_record does in fact follow around the DBAPI connection, > however the .info dictionary is given here as the primary way to track > things with a DBAPI connection. .info is available on Connection, the > connection record, and the pool wrapper, and it will track the DBAPI > connection for its full lifespan, until the connection is closed. So put > whatever memoizations you need into the .info dictionary, and then you can > pretty much set / reset the state with any of the pool events. > > > > Thanks in advance for any advice here. > > Kent > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "sqlalchemy" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sqlalchemy+...@googlegroups.com <javascript:>. > > To post to this group, send email to sqlal...@googlegroups.com > <javascript:>. > > Visit this group at http://groups.google.com/group/sqlalchemy. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.