Just curious and learning here -- There are two separate issues here, aren't there? (1.) Atomicity of the transaction, taken care of by the above discussion, and (2.) what if there was a need to have it be not only atomic but consume as little time as possible between the read and write, let's say for financial purposes?
All I really know about (2.) so far is that it's a fine concern in theory, but in practice there are so many things affecting the timing that it's impractical to worry about it beyond just coding for atomic transactions and trying to minimize bottlenecks in the system. On Jun 17, 7:17 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Jun 17, 2011, at 8:41 AM, Moch Ramis wrote: > > > 2011/6/15 Michael Bayer <mike...@zzzcomputing.com> > > Assuming you're talking about the ORM. You can of course emit the exact > > SQL you refer to any time using execute() from an engine, connection, or > > session. The ORM works within a transaction at all times. so an > > expression like: > > > myobject = MyObject(id=5) > > myobject = Session.merge(myobject) > > Session.commit() > > > will perform the equivalent steps, subject to the transaction isolation in > > effect. > > > I'm not sure this will do the trick as i don't know if the object i'm > > looking for already exist or not. thus, i don't have it's id ( i don't even > > know if a range of id is free or not). > > OK then similar, > > myobject = s.query(MyClass).filter(...).first() > > if myobject is None: > # ... etc > > > > > To lock the row during the SELECT, you can use > > query.with_lockmode(True).filter(criterion) to SELECT the row with FOR > > UPDATE, will return None if the row does not exist. > > > I'm not sure a lockMode is necessary. > > right actually this doesn't apply here since we are talking about an INSERT > not an UPDATE, sorry. > > > However, I'm far from being an expert or to clearly know the internal > > mechanisms of DBMS, but reading the Deadlock example in the part 12.3.3 of > > this page of the postgresql documentation, I thought, that sending a bunch > > of requests in one transaction would allow to do it as if it was all at > > once, avoiding any conflicts that could occurs if two almost identical > > requests were overlapping (like one executing its first statement, the > > other the second ect..). > > yah Session is in a transaction which completes when you call rollback() or > commit(). I don't think there's any additional atomicity to an "IF NOT > EXISTS...SELECT" type of phrase versus a SELECT then an INSERT (if there is > that would be surprising). -- 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.
