Found another bug and the warning is gone; can't pinpoint why though ... On Mar 30, 1:03 am, lars van gemerden <[email protected]> wrote: > 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.
