I was getting some strange transaction isolation behavior with SQLAlchemy (0.7.2), psycopg2 (2.4.2), and PostgreSQL 8.4. In order to investigate I wrote up a usage sequence that does this:
1. starts a transaction with a session (s1) 2. starts another transaction with session (s2) 3. updates a value in s1 and commits it 4. reads the value back in s2 using the ORM... - and it does not get the updated value, although with READ COMMITED it should 5. reads the value back in s2 using a direct s2.execute statement... - and it DOES get the updated value (??) I don't understand why the ORM-triggered read (which does emit SQL) is not getting the update value, but the direct statement is getting the update. When the logger emits SQL I thought it always sent the SQL to the database. Is this a correct assumption? Here is my complete (and somewhat verbose) test code that shows the behaviour... http://static.inky.ws/syn/325 The postgres engine string obviously needs to be changed appropriately. And WATCH OUT for the drop tables code in there for anyone who tries this, if nutty enough to point at a live database. What is going on? I expect/hope it is something dumb on my end, but I just don't see it. Thanks! -- 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.
