For performance reasons I am converting some operations from ORM to SQL Expression syntax. In other words instead of session.query(...) I'm now using select(...).execute(). This has led to a couple of questions:
1) I was relying on thread local sessions to handle all the ugly details for me when executing multiple concurrent operations. When executing a select statement directly, do I still get a separate connection per thread? By enabling connection pool logging it APPEARS that I do. Is this correct or should I user session.execute(...) instead (even though I do not require transactions for these statements)? 2) When I close a session, the documentation says that the SQL transaction is rolled-back but I do not see this if I enable logging. For example, if I do: MyClass.get(1) # Elixr method, same as session.query(MyClass).get(1) session.close() I get log output like: 2009-01-14 23:26:08,664 - sqlalchemy - INFO - Connection <_mysql.connection open to '192.168.0.1' at 999baf4> checked out from pool 2009-01-14 23:26:08,665 - sqlalchemy - INFO - BEGIN 2009-01-14 23:26:08,671 - sqlalchemy - INFO - SELECT .... (truncated for brevity) 2009-01-14 23:26:08,763 - sqlalchemy - INFO - Connection <_mysql.connection open to '192.168.0.1' at 999baf4> being returned to pool Should I be worried that there is not an explicit ROLLBACK generated or is that handled when the connection is returned to the pool? Thanks in advance, Shawn --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
