Hi all!
I'm looking for a programming pattern to deal with a radio button like
behavior, thatis in a group of rows, all with same group_id, only one
can have a flag column set as true. Without using table triggers that
make all rows in the group lose the flag if the updating row carries it
On Sep 8, 2011, at 9:32 AM, Vlad K. wrote:
As a by the way to this question, I've noticed that the order of queries
given before flush() is not preserved for the flush(). Any way to enforce the
order?
Trying to parse what this means. Suppose you did a single SELECT, loaded five
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
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)
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
On Sep 8, 2011, at 6:00 PM, Vlad K. wrote:
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
Yes, I earlier said it was merge() that took effect before update()
because that's how it looked like (didn't know about autoflush). Putting
a sleep before update() and merge() showed that merge() issued no SQL
because the autoflush (as you say) of the update() practically synced
the session
