On Dec 11, 2013, at 8:02 AM, Tim Kersten <[email protected]> wrote: > The before_delete and after_delete shouldn't make use of the current Session > though, according to > http://docs.sqlalchemy.org/en/rel_0_9/orm/events.html?highlight=after_delete#sqlalchemy.orm.events.MapperEvents.after_delete > > Book keeping within the one transaction becomes somewhat difficult when those > are the only places to catch deletes caused by becoming an orphan. Any > suggestions on how one might go about adding book keeping rows with this > information to the Session? i.e. Like in the after_delete so that it picks up > orphan deletes?
you can make use of the Session within the mapper-level events, you just can’t rely upon any actual changes you make to that Session actually being acted upon within the flush, as the flush plan has already been determined at that point. In fact logic was added in recent months that will cause the Session to flush again if events have dirtied up the session within the flush, so these warnings are already becoming too strong for what the current reality is - I would like to dial them back a bit, although this would require nailing down exactly what cases still won’t work as expected.
signature.asc
Description: Message signed with OpenPGP using GPGMail
