On Fri, Jul 25, 2014 at 7:55 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > Don't objects potentially have this problem anyway, in the sense that if > they are accessed TWICE after a commit, the second access will use the data > cached from the first, and could again be out of date? > > > only if you have a low transaction isolation level set up. The Session > tries to make a choice as to the most reasonable place that concurrent > changes should be anticipated. Transaction demarcations are the best place. > If you are expecting to code your app to specifically expect READ COMMITTED > or READ UNCOMMITTED behavior where your transaction relies upon seeing a row > change value from a concurrent transaction, that’s a special use case, in > which case you can use expire() for those object that have this requirement. > The ORM Session can obviously not guess when such an expiration is to be > detected otherwise.
I don't see how transaction isolation levels relate to this. The effect of disabling expire_on_commit is that of not seeing subsequent commits. It would be a fictious DO NOT READ COMMITTED level. Having it on, somewhat caters to possible SERIALIZED settings, where strict ordering is to be expected, since without serialized transactions there's no way expiring helps correctness in any way. None of those seem overly common to me, so I don't see how one can ignore the serialization level in effect or possible concurrent updates that are happening at the same time, with or without expire_on_commit. IMHO, expire_on_commit is something that really has no sensible default. You pick your own, the library authors pick one default because, well, why not? For the record, I'm using expire_on_commit=off, because I also use model instances outside the scope of their originating transaction. I've had no problems with it, but I did have to be very careful with the semantics and lifetime of those objects, and of expiring manually anything I put on concurrently-accessed structures, lest someone modify it before the session's scope is over and it gets (or tries to be) committed to the DB. -- 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.
