On Fri, Jul 25, 2014 at 10:09 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: >> 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. > > Maybe "expire on begin" might be useful. So your data is still there after > commit, but if you start a new transaction, then things refresh. I'm up for > it in a 1.0 release, if you think it's useful. Though explaining to > everyone another option...what a PITA....
I don't see how that'd work. On session.add? When set as dependent of an object of another (active) session? Seems very error prone to make it too automatic. All in all, the current state isn't bad. It's understandable, and controllable. I'm just saying there's no one-size-fits-all. -- 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.
