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

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()
- 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
Here is the stack at this point:
  self._prepare_impl()
  self.session.flush()
  self.uow.flush(self, objects)
  session.commit()
  self.transaction.commit()
  self._prepare_impl()


-

On May 23, 6:07 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On May 23, 2008, at 10:44 AM, Moshe Cohen wrote:
>
> > Evidently, when the autoflush occurred within the commit(), the
> > database transaction COMMIT itself happened before the call to
> > after_update() .
>
> thats not how it works.   the steps are:
>
> session.commit()
>      session.flush()
>          mapper._save_obj()
>               before_update/before_insert()
>               UPDATE/INSERT
>               after_update/after_insert()
>      engine.commit()
>
> > The fact is that explicitly calling session.flush() immediately
> > before calling session.commit(), changed the final state of the DB.
> > This means the commit() with autoflush is not equivalent to  flush
> > and then commit.
>
> it would be helpful if you could provide the evidence you're basing
> this on.  it sounds like your Session is not actually within a
> transaction when you call flush(), so that the flush() begins and
> commits its own transaction.  If transactional=True, this would be a
> bug.  But then calling session.commit() should raise an error, so not
> sure how you'd achieve that behavior, and I'm not seeing any codepath
> that could produce that behavior - when transactional=True, a begin()
> is issued in all cases before any flush call.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to