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 objects. Then changed them and did a flush. What is the "order of queries" to be preserved? Guessing, perhaps you mean, the order in which a particular object became present in the Session, that's the order in which UPDATE statements should be emitted. UPDATE statements are in fact ordered in terms of the primary key of the row. The reason for this is to minimize the chance of deadlocks. Process A and process B both need to update primary key 1 and 2 in a table. If process A starts with 1 and process B starts with 2, you have a deadlock. So an ordering that is deterministic across transactions, where PK ordering is a pretty good assumption in most cases, is the best behavior here. If you need UPDATE statements in a specific order, you can A. emit flush() specifically against a Session in which you're controlling what's "dirty", B. use query.update(), C. use the Core SQL language instead of the ORM for this particular series of operations (though query.update() likely a happy medium). -- 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.
