OK, thanks, I still get the warning in some cases and i am still zooming in on the problem for a small test case.
At least i have solved the problem of the id of InstrumentedLists changing after commit(by bypassing one layer of recursion in the xml tree parsing, i am not looking up the id of the IList anymore). Cheers On Mar 29, 4:20 pm, Michael Bayer <[email protected]> wrote: > On Mar 29, 2012, at 9:50 AM, lars van gemerden wrote: > > > I have found that this specific behaviour (re-initialization of the > > InstrumentedList) does not happen if "expire_on_commit = False" is set > > on the sesssion. However this leads to other errors in my code. > > > I guess I don't quite understand why expire would be called after a > > commit; shouldn't the commit result in the session being perfectly > > synchronized with the DB? > > It does. The expire of the attributes doesn't cause any SQL to be emitted > until you access the attributes, in which case a new transaction is begun > (note the DBAPI's default mode of operation is to always be in a transaction, > and SQLAlchemy does not challenge this). In between your commit() and the > start of a new transaction, any amount of state within the database may have > been changed by other transactions. > > If expire_on_commit=False is leading to errors, that would imply that this is > actually happening in your case. -- 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.
