On Jul 25, 2014, at 6:22 PM, Paul Molodowitch <elron...@gmail.com> wrote:
> Hi all - so I'm thinking of disabling the expire_on_commit property for my > default sessionmaker object, and I was wondering what the potential issues > with this were. Is it simply that the next access of the data on it could be > using out-of-date information? pretty much, yup > 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. > > To give some background - we're in the middle of converting an existing > codebase to use sqlalchemy, and there are number of classes that act both as > database wrappers, AND "data structures." That is, when first constructed, > they are populated with data from the database; but from then on out, they > just keep the cached data. So they would behave similarly to ORM-mapped > objects, if expire_on_commit is False. The thinking here is that for most of > these classes, the data changes fairly infrequently, and it's not > catastrophic if it's somewhat out of date. Also we don't want to keep hitting > the database more than necessary... and, finally, we might need to have > access to the cached data for a long time (ie, as long as the user has a ui > window open). > > -- > 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. -- 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.
