Ive made an adjustment in r5720 such that _expire_state() will exclude  
unloaded, deferred attribute names from the list of attributes to  
expire.  So deferreds won't load in that specific case.   Otherwise,  
explicitly expiring the deferred attribute or expiring when the  
deferred attribute was loaded will load the attribute on access, as  
will session.refresh().   session.refresh() might warrant adjustment  
as well but that's not a very common operation compared to full  
instance expiration.

On Jan 23, 2009, at 6:20 PM, Jon Nelson wrote:

>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to