Re: [sqlalchemy] ORM events order

2013-12-06 Thread Tim Kersten
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 > 
> 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 
> > > 
> wrote: 
> > 
> >> 
> >> On Dec 5, 2013, at 10:51 AM, Tim Kersten > 
> 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+...@googlegroups.com . 
> > To post to this group, send email to 
> > sqlal...@googlegroups.com. 
>
> > 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 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.


Re: [sqlalchemy] ORM events order

2013-12-05 Thread Michael Bayer

On Dec 5, 2013, at 12:14 PM, Tim Kersten  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  wrote:
> 
>> 
>> On Dec 5, 2013, at 10:51 AM, Tim Kersten  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


Re: [sqlalchemy] ORM events order

2013-12-05 Thread Tim Kersten
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?


On 5 Dec 2013, at 16:01, Michael Bayer  wrote:

> 
> On Dec 5, 2013, at 10:51 AM, Tim Kersten  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.


Re: [sqlalchemy] ORM events order

2013-12-05 Thread Michael Bayer

On Dec 5, 2013, at 10:51 AM, Tim Kersten  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.




signature.asc
Description: Message signed with OpenPGP using GPGMail


[sqlalchemy] ORM events order

2013-12-05 Thread Tim Kersten
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. 

Cheers,
Tim

-- 
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.