Yes that's how I know the order of events. I just checked the logs again and put some sleep() between update() and merge(). It appears that the update() does some kind of implicit flush because that "commits" the dirtied properties of the row instance BEFORE the update is issued, so that when merge() comes, everything appears in sync to the session.
So, in short, I'm doing this: 1. select row or new 2. assign some values to it 3. issue an update to a group of other rows (this should happen FIRST) 4. merge the row with db, flush, commit. (this should happen SECOND) What I'm getting: 1. SELECTed row data 2. UPDATE on changed values (implicit flush of dirtied session data) 3. UPDATE as expected in step 3 above 4. COMMIT .oO V Oo. On 09/08/2011 10:04 PM, Michael Bayer wrote:
On Sep 8, 2011, at 3:32 PM, Vlad K. wrote:For example the following: row = session.query(Model).filter_by(pkey=pkey_value).first() or Model() row.some_field = 123; ... session.query(Model).filter_by(nonprimary_key=some_value).update({...}, false) session.merge(row) session.flush() When flush() gets called, the merge() is executed (query sent to DB) before the update called above it, in this particular example.That isn't correct, query.update() emits UPDATE immediately. Do you have a SQL log illustrating what is being emitted ?
-- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
