On Sep 9, 2011, at 12:57 AM, Russ wrote:
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
Thanks for clarifying with a full answer!
This should not be construed to mean that you should only use the ORM
with SERIALIZABLE isolation. It's instead just something to be aware of.
You can of course expire any object or individual attribute at any time.
In
this case, if you were to add
On Sep 9, 2011, at 10:39 AM, Russ wrote:
Thanks for clarifying with a full answer!
This should not be construed to mean that you should only use the ORM
with SERIALIZABLE isolation. It's instead just something to be aware of.
You can of course expire any object or individual attribute
when you say query(Class).filter(criterion).one(), that always emits SQL.
It's an open-ended query, and SQLalhcemy doesn't know that s2c1 is the
object which corresponds to the SQL you're about to emit. When the row
comes back, it then extracts the primary key from the incoming row,
On Sep 9, 2011, at 5:11 PM, Russ wrote:
when you say query(Class).filter(criterion).one(), that always emits SQL.
It's an open-ended query, and SQLalhcemy doesn't know that s2c1 is the object
which corresponds to the SQL you're about to emit. When the row comes back,
it then extracts
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
