On 11 Dec 2013, at 16:32, Michael Bayer <mike...@zzzcomputing.com> wrote:
> > On Dec 11, 2013, at 8:02 AM, Tim Kersten <t...@io41.com> 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. > Excellent, thanks. -- 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.
