Ok, Mike. Thanks. Ended up removing the trigger from the model and pushing that code to the controller, so that "foo" updates the "bar" attribute after form data with UserCourse objects is handled.
On Wednesday, July 2, 2014 9:42:11 PM UTC-4, Michael Bayer wrote: > > > On 7/2/14, 2:59 PM, Brian Findlay wrote: > > Mike, thanks for the response. > > > > (1) "foo" updates a particular User attribute based on a calculation > > performed on the user.courses collection. I'm listening for the "set" > > event on UserCourse objects to trigger "foo" to update that User > > attribute, but that isn't working with new users because -- as you say > > -- the "set" event is called before the actual attribute association > > occurs. What is the first event I could listen for that would > > recognize the new attribute association? > in that event I only see "grade" being set so it's not clear to me what > the bigger picture is. If this is all within the association proxy > setup and within when a new UserCourse is created, I'd have to step > through w/ pdb to see when things happen, but often with these assoc > proxy cases, building out a custom proxier that does the things you want > is often necessary if you really want sophisticated behaviors. > > we don't really have a solution to the attribute events being before the > thing is set. adding all new "after set" events isn't possible without > adding even more latency, and attribute mutation operations are already > a huge performance bottleneck. Association proxies and attribute > events are both handy but they only go so far in their capabilities. > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
