Unique constraints have worked well. Thanks!
On May 29, 1:44 pm, Michael Bayer mike...@zzzcomputing.com wrote:
yup
On May 29, 2012, at 1:01 PM, Jeff wrote:
Thanks Michael,
Just to make clear what exactly begin_nested() is contributing:
Normal case:
session.rollback() goes
Thanks Michael,
Just to make clear what exactly begin_nested() is contributing:
Normal case:
session.rollback() goes back to the last session.commit()
session.begin_nested() case:
session.rollback() goes back to the last session.begin_nested() or
session.commit(), whichever occurred last.
The unique constraint sounds like a workable solution! I'll implement
that with a try/except and report back if that was effective. Thanks!
On May 28, 5:43 am, Simon King si...@simonking.org.uk wrote:
On Sun, May 27, 2012 at 6:18 PM, Jeff jeffalst...@gmail.com wrote:
Thanks,
I have indeed
An option to add along to the unique constraint, if you expect to get
collisions often, is to use a SAVEPOINT so that a process can roll back
partially if this particular INSERT fails, then use the row. The Session
offers SAVEPOINT via begin_nested():
session.begin_nested()
try:
Thanks,
I have indeed spent a lot of time looking at SELECT FOR UPDATE, but as
far as I can tell that locks rows that have been selected. That is not
helpful in this use case, in which the issue is rows not existing, and
then later existing. Am I misunderstanding?
On May 27, 11:48 am, A.M.
Hmmm. It also appears that the 4 step solution I gave above doesn't
work consistently. Any ideas as to why not?
On May 27, 1:07 am, Jeff jeffalst...@gmail.com wrote:
I have multiple processes accessing a table. All of these processes
want to read a set of rows from the table, and if the rows
