Thanks for your help and insight, Michael! For now, since my program was using SA 0.3, it only deals with instance-wide expiration, so for now I have just wrapped the AttributeImpl.get method to do a full refresh of the instance if its state is expired.
On Apr 5, 3:47 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote: > Michael Bayer wrote: > > John Huang wrote: > > >> Now I understand that refresh will cause a reload of all attributes > >> based the primary mapper. However, the reason that I want to use > >> expire instead of refresh is because there may be places in my code > >> where the same object will be expired multiple times before an > >> attribute is accessed, and I if I were to change all of my calls from > >> expire() to refresh(), then it would hit the database multiple times. > > >> Basically, I want to know if there is a way to expire an object such > >> that it will reload all attributes (scalar and eagerloaded) upon the > >> next access. > > > Not currently. The mechanics of triggering a relationship() reload are > > more complex than that of the mechanics of an individual attribute reload. > > Its a one line change to have the "unexpire" callable include > > relationships in it's load, which works for a simplistic eagerload case. > > But since most of those are lazyloads, the attribute accounting is not > > currently smart enough to reconcile all of it, and many tests fail. The > > expiration accounting in 0.3 was much more primitive as expiration was not > > a common event in that version. > > I've addedhttp://www.sqlalchemy.org/trac/ticket/1763for this, which > illustrates within a new test the basic problem the behavior introduces > (its solvable, but not easily). The behavior is also not currently > compatible with the "unexpire" behavior for joined-table loaders, which > emit a query that includes only those entity tables which need to be > refreshed. > > > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups > >> "sqlalchemy" group. > >> To post to this group, send email to sqlalch...@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. > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to sqlalch...@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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
