PLEASE IGNORE PREVIOUS.
It turns out that explicitly flushing does change the order (made a
silly coding error before).
I am all set, but the question remains why autoflush isn't enough.
On May 23, 2:15 pm, Moshe C. [EMAIL PROTECTED] wrote:
I have a mapper created with a mapper extension that
On May 23, 2008, at 7:26 AM, Moshe C. wrote:
PLEASE IGNORE PREVIOUS.
It turns out that explicitly flushing does change the order (made a
silly coding error before).
I am all set, but the question remains why autoflush isn't enough.
autoflush will occur before every query execute and
Evidently, when the autoflush occurred within the commit(), the database
transaction COMMIT itself happened before the call to after_update() .
The fact is that explicitly calling session.flush() immediately before
calling session.commit(), changed the final state of the DB.
This means the
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()
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
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
OK, thanks very much.
My wrong assumption was that saves within the hook functions will make
it into the current flush.
Preceding the commit() with a manual flush, causes the commit to flush
this new saves (that occured in the flush).
Makes sense now :-)
On May 24, 2:52 am, Michael Bayer
