On Thu, Apr 2, 2009, Jyotirmoy <jmoy.mate...@gmail.com> wrote: > > On Apr 1, Yassen Damyanov <yassen....@gmail.com> wrote: >> You may prefer to use session.merge() leaving the SELECT and the >> subsequent decision to INSERT or UPDATE to SQLAlchemy >> (seehttp://www.sqlalchemy.org/docs/05/session.html?highlight=merge#merging) >> >> The main section of your example should look like this then: >> >> ---snip----------------------- >> id = 55 >> val = random.choice(range(1000)) >> t = T(id, val) >> session = Session() >> session.merge(t) >> session.commit() >> ---snip----------------------- > > This also has a race condition, as another process running the same > code can commit between the merge and commit in this process. So the > only solution seems to be to use table locks, as your alternate code > does. I was wondering if there could be some way to make SA do the > locking on its own rather than my having to use explicit SQL or > alternatively issue something like MySQL's 'INSERT..ON DUPLICATE > UPDATE'.
Correct; however I don't think SA supports locking generically as it is too backend-specific... Not sure if this is a good advice, but extending SessionExtension (in orm/session.py) and providing lock and unlock statements in after_begin() and after_commit() (or after_flush()? I am new to SA so I am guessing most of the time... sorry). Y. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
