Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Michael Bayer wrote: HD - yah, youre good, this is how it works right now. Will whatever changes you guys are talking about upset this use case ? I like the simplicity of this, and it has worked well for alot of the stuff I do. Thanks Huy

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

On Apr 4, 2006, at 9:04 PM, Daniel Miller wrote: I think that last thing (getting the connection from the session) ties into this. However, we better start a new thread for that. I'll do that now. ack no more threads ! im too overwhelmed by this one. im trying to work up another pr

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Michael Bayer wrote: cn = SQLEngine.connection(...) # get pooled connection what is cn ? since it has begin/commit stuff that returns SQLTransactions, it cant be just a striaght DBAPI connection. Right now, the SQLSession object is most analgous to this, it is a connection-holding object

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

daniel - glad youre involved with this discussion since youre the "main guy" besides me with regards to objectstore.begin/commit design :) your API below looks very nice. but there are some issues and questions: cn = SQLEngine.connection(...) # get pooled connection what is cn ? sinc

Re: Re[8]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

On Apr 3, 2006, at 8:51 PM, Gambit wrote: If this is accurate, a couple questions spring to mind: First, when you do session.flush() without a surrounding transaction, does all the UOW actual commits occur within it's own transaction? (I sorta assumed this is yes, but just want to make sure)

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

HD - yah, youre good, this is how it works right now. On Apr 3, 2006, at 8:53 PM, HD Mail wrote: Michael, This thread is making me think that I am using transactions in SA incorrectly. I use a transaction decorator like below def transaction(func): def trans_func(*args, **kws):

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

First, let me state that engine.begin/commit has always confused the heck out of me so I just acted like it didn't exist. Why do we need it? If transactions are needed at the connection level, then use the connection.begin/commit for that (maybe connection.begin() should return a SQLTransaction

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Michael, This thread is making me think that I am using transactions in SA incorrectly. I use a transaction decorator like below def transaction(func): def trans_func(*args, **kws): log.warn('* TRANS BEGIN ***') engine.begin() try: f = func(*args, **k

Re[8]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

So from what you said below: trans = engine.begin() # do some explicit SQL trans.commit() # Commits all the explicit SQL, as we'd expect objectstore.push_session(objectstore.Session(import_imap=True)) trans = session.begin_transaction() foo = Foo() bar = Bar() # other UOW behavio

Re: Re[6]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

gambit - the various push-based interfaces have some room for streamlining. but the more immediate issue is that everyone is confusing engine.begin()/commit() with objectstore.begin()/commit(), as youve done below. I am beginning to think a somewhat radical API change might be the only w

Re[6]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Hey Michael, Just looking at your usage there, but would it make any sense at all to have engine.begin() and engine.push_session() turn into one method? Does it make sense to create multiple sessions if you're not going to be doing simultaneous transactions? I think I'm looking for a way to some

Re: Re[4]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Yah, ok , youre getting into features that were just written a few weeks ago, if you want simultaneous transactions, theres a feature on engine called "push_session"/"pop_session". you should not be creating multiple engines for the same connection (i mean, you can, but the experience will

Re[4]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Hello Michael, Monday, April 03, 2006, 11:33:13 AM, you wrote: So if I understand correctly if I want several simultaneously opened transactions I have to construct several engines? Please correct me if I am wrong. So I changed behaviour of my program to following: When tab with object opened fo

Re: Re[2]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

for any kind of transactional locking to occur, you have to use explicit sessions with the engine. SQLAlchemy has two different levels of operation; the "engine" level, which deals with SQL statements and connections, and the "object relational mapper" level, which deals with the state of objects

Re[2]: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Hello Michael, Monday, April 03, 2006, 1:05:27 AM, you wrote: I am building a GUI program, where opertators will modify database by hand. So if two operators open one row of table for edition at the same time and then one commits and then second commits then changes made by operator who commits f

Re: [Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

"for update" is not a behavior SA's mapper was really designed to support. if you do not use an explicit engine transaction, then the connection object used for each operation will possibly be different each time, and also a new cursor is used. its not like it will always be this way, but ive nev

[Sqlalchemy-users] Problem with SELECT ... FOR UPDATE;

Hello, I have a problem with "SELECT ... FOR UPDATE;" command. I have a MySQL database, table created with TYPE=INNODB engine specification with proper transaction isolation level set. I want to issue "SELECT ... FOR UPDATE;" command to lock specific row of table for updates. Here's a sample sc