On May 23, 2008, at 6:54 PM, Moshe C. wrote:
> > I traced what is happening in the code. > I don't fully understand it but I hope the following will help. > The crucial point is that in my after_update() method I create a > mapped object and call session.save() using the same session (but > different table). session.save() within a mapper extension's before/after update/insert does nothing for the span of that flush. The full list of objects to be sent to the database is already determined at that point and new objects in the session won't get flushed until the next flush (which in this case is outside of the commit()). if you'd like to affect the flush plan upon flush(), you'd have to implement before_flush() on a SessionExtension. Or just stick to manually calling flush() if that solves the particular ordering issue. > This is the sequence of events: > - I call session.commit() > - session._prepare_impl is called and the "if self.autoflush:" is > entered and flush() is called > - my after_update() is called > - session commit is called again from within unitofwork.flush() this is normal. the unitofwork has its own "transaction", which may or may not be a subtransaction. in this case, its a subtransaction; nothing actually happens. > > - it calls self.transaction.commit() which calls self._prepare_impl() > - In this call to _prepare_impl() the "if self.autoflush:" is not > entered and there is no flushing this is because the flush guards against reentrant calls to itself. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
