On May 11, 2011, at 7:44 AM, Luper Rouch wrote: > On May 10, 8:16 pm, Michael Bayer <[email protected]> wrote: >> On May 10, 2011, at 2:12 PM, Michael Bayer wrote: >> >> >> >>> The purpose of events is to provide hooks into points inside of >>> SQLAlchemy's internal processes that would otherwise be impossible. >>> Adding events outside of its internal processes just to suit various use >>> cases begins to turn it into a framework, which is not what SQLAlchemy is. >> >> though let me add, the new events system is fairly easy to extend - a custom >> Session subclass and a custom event base class could extend the event style >> of coding to a wider range of operations. >> >> http://www.sqlalchemy.org/docs/07/core/event.html > > How would you implement something like outer_after_update() with the > current events system ? SessionExtension.after_flush_postexec() seems > to be the only event executed out of the flush process, but how do you > retrieve the instances that were modified during the flush ?
The "outer_after_update()" event you described in your diagram, as it was illustrated as after the "commit", would be the "after_commit()" event, an event called after the commit(). Though that seems like maybe not what you meant. I'm not sure where you'd want this event to occur. inside the after_flush() event, the "new", "dirty" and "deleted" lists are still present. In after_flush_postexec(), the pre-flush state is closed out so there's no built in way to see what happened, unless you kept track of it separately via before_flush() or after_flush() (which is absolutely doable). But emitting flush() within flush() is a bad idea and should not be necessary. The way a unit of work functions is that the full series of operations to be performed is calculated first, then executed as a series of commands. So there can't really be any event inside of that series that modifies what will actually happen, in terms of the flush plan. If you need the flush plan to have more elements in it, you need to make those decisions up front within before_flush(), or if possible, just within your object model (such as, intercept attribute events, make something happen in response to some attribute or collection being modified). > And how > can you tell if an insert or an update occurred for each instance ? an object would be present in "new" or "dirty" in the before_flush() or after_flush() stages. Or in before_flush, it wouldn't have an identity key, i.e. attributes.instance_state(myobject).has_identity. -- 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.
