> as your list comprehension completes, only the most recent value remains > strongly referenced. Python garbage collection has kicked in and cleaned out > the first T instance, only the second remains.
Thanks. That makes sense. > If you weren't using autocommit=True, a transaction would > remain open throughout the scope of your working with T objects > in the session. If you were to then use SERIALIZABLE > transaction with PG, this would prevent the inconsistent read > from occurring. Allowing transaction isolation to be useful is > why autocommit=False is the default and we don't talk much > about autocommit=True. Once you were to call session.rollback() > or session.commit(), the state of each T still in memory would > be expired and you'd see the 'c' value for both T objects after > you re-access them in the subsequent transaction that starts up > the moment you query again. In this way, the Session doesn't > have to reinvent transactional concurrency behavior, or make > continuous expensive and complicated guesses as to when it > should expire which attributes - it very simply assumes the > greatest data consistency with a SERIALIZABLE transaction, and > has only simple decisions to be made regarding attribute state. > That doesn't mean you have to use SERIALIZABLE. You'd use it > typically if you are expecting to deal with individual rows in > a concurrent fashion. Otherwise the default of READ COMMITTED > is usually fine for most needs. Ok. That also makes sense. I retested with an isolation level of READ COMMITTED, autocommit=False, and had both queries issued within the same transaction; the second query has the same discrepancy in the result set (i.e., one row has a 'c' and one row has a 'b')--because of the identity map. And I gather from your explanation that this to be expected. I.e., the READ COMMITTED isolation level semantics, as supported by SQLAlchemy is slightly different than true READ COMMITTED (where both rows should have had c's). Is that a fair statement? -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
