I was debugging some stuff recently and noticed different behavior in one of my applications than I was expecting. The behavior is the undesirable execution of some sql. The sql is used to populate the value of a column_property. The column_property has been deferred, however, and the property isn't even being accessed. I narrowed it down to a strange interaction with transactions:
First, I'm setting up my session like this, if it matters. DBSession = scoped_session( sessionmaker(bind=engine, autoflush=False, autocommit=True) ) ... and later I have a mapper defined with one of the properties being: 'user_count': column_property(..., deferred=True) Assume the property is on an 'Account' object. For apps which do *not* demonstrate this behavior, they typically do this: sess = DBSession() sess.begin() .... sess.rollback() or sess.commit() In this case, the app does this: sess = DBSession() sess.begin() accounts = get_the_accounts(...) sess.rollback() for account in accounts: # ANY access to the account object here causes it to be re-loaded, # including *all* columns and properties, even those that were # deferred. print account.anything Thus, accesses to objects loaded by a session which has been rolled back or committed not only re-load the object but all of the deferred attributes as well. I even tried using deferred(...) on a standard column and that, too, was loaded when I didn't expect it to be. If I remove all begin/commit/rollback things work as expected. -- Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
