On Apr 11, 2012, at 5:11 PM, Paddy Mullen wrote: > > It seems like I might have a common usecase here. What would you think of > adding "after_insert_committed", "after_update_committed", and after > "delete_committed" events to the Table object. I would be interested in > taking a crack at it.
At some point I'll be adding features to the Session events such that filters can be applied, which will then emit a "sub-event" based on filtering for all objects with certain characteristics - a certain class, or their presence in .new, .dirty, .deleted (these are public lists). These will be available for events like before_flush and after_flush. Within after_commit(), things are trickier as we have only a list of items that entered the session via .new and items that entered the session via .deleted, but not the public version of these lists, they're separate lists used just to maintain things in case we rollback. These collections don't cover objects that were garbage collected, so there really can't be such an event that will "work" the way everyone would expect it to. So your best bet is to use before_flush, after_flush, or even after_insert/after_update, and populate a collection that's associated with the Session. -- 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.
