On Dec 5, 2013, at 12:14 PM, Tim Kersten <t...@io41.com> wrote: > thank you. > > What of the relative ordering of the different ORM event types? i.e. > > before_flush > before_delete > after_flush > etc > > When looking at before_flush I see the before_delete has not yet been fired, > yet is has been fired in the after_flush. Is this guaranteed to always be the > case?
yes, before_flush and after_flush provide boundaries around the mechanics of the flush itself. before_delete as well as the other mapper-level events like before_update before_insert after_update etc. are all within the flush mechanics. you can’t necessarily rely upon the ordering of insert/update/delete events within the flush however, relative to different objects and especially across different kinds of objects. The mapper-level flush events are fired right as individual batches of objects are being prepared for INSERT/UPDATE/DELETE statements. > > > On 5 Dec 2013, at 16:01, Michael Bayer <mike...@zzzcomputing.com> wrote: > >> >> On Dec 5, 2013, at 10:51 AM, Tim Kersten <t...@io41.com> wrote: >> >>> Hi Folks, >>> >>> Is the order ORM events ( >>> http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html ) are fired in >>> deterministic and guaranteed to be the same every time? I've searched the >>> docs and google but couldn't anything relating to their relative order. >> >> >> the events are ordered. when you do an event.listen it appends the event >> listener to a list of listeners. the events are fired from the beginning >> of the list on forward. there’s actually an undocumented argument to >> event.listen() “insert=True” that will cause the listener to be inserted at >> position zero rather than appended. >> >> the reason the order of events is not really mentioned much is because >> there’s complex cases where the order of listener application has not been >> evaluated or tested. When you make use of mapper or instrumentation events >> against un-mapped base classes and such, the actual append() operation >> doesn’t occur until later, when classes are actually mapped, and this works >> by shuttling the event listener functions around to those classes. In these >> cases we don’t as yet have guarantees in place as to the order of the >> listeners being first applied, e.g. if you had a class that is a product of >> two mixins, and each mixin has listeners applied to it, that sort of thing. >> >> however, the order of listeners once applied should definitely be the same >> each time assuming no changes to the listener collections. >> >> > > -- > 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/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
