Thank you very much On Thursday, December 5, 2013 5:20:57 PM UTC, Michael Bayer wrote: > > > On Dec 5, 2013, at 12:14 PM, Tim Kersten <[email protected] <javascript:>> > 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 > > <[email protected]<javascript:>> > wrote: > > > >> > >> On Dec 5, 2013, at 10:51 AM, Tim Kersten <[email protected] <javascript:>> > 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 [email protected] <javascript:>. > > To post to this group, send email to > > [email protected]<javascript:>. > > > Visit this group at http://groups.google.com/group/sqlalchemy. > > For more options, visit https://groups.google.com/groups/opt_out. > >
-- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
