Re: improving async support in psycopg

On 29/03/10 09:13, Federico Di Gregorio wrote:
> On 28/03/2010 10:42, Jan Urbański wrote:
>> Yeah, there are places where psycopg2 issues queries behind your back :(
>> That's why I said that a user of the async features would probably have
>> to set the transaction isolation level to autocommit and issue his own
>> BEGINs and COMMITs from a Cursor.execute() instead.

> code using psycopg in async mode will usually be some asynchronous
> framework of some sort and not code written directly by the user. Then
> it make sense to depythonize the API a little bit and let the client
> code use psycopg as a facility to issue asynchronous queries. Also I
> don't think that keeping a single path in the code is such a good idea,
> so why not have a connect() call that when invoked with async=True takes
> a completely different path and setup everything for async mode? It will
> put the connection into autocommit and disable (meaning that they will
> raise an exception) methods such as commit(), rollback() and
> set_transaction_isolation(). We just need a list of what psycopg should
> or should not do.

This sounds good. In my patches the connect() call is choosing different 
codepaths sync and async connecting (conn_sync_connect vs
conn_async_connect).

The behaviour I proposed in a previous mail was that repeated execute() 
attempts, commit() and rollback() were blocking, so app code would have 
to make sure it's not calling and take care of serialising execute() 
calls. Same for fetch() - if the cursor has not finished executing yet, 
it was blocking until it got the result. That was an attempt to make 
async cursors as safe as possible: that way you could almost use them as 
sync cursor and should not really notice. But I guess there's no value 
in that.

Maybe it could work like this:
   * async connections start in isolation level 0
   * connection methods that raise an exception if called on an async 
connection:
     * commit
     * rollback
     * set_isolation_level
     * set_client_encoding
     * lobject
     * named cursor creation
   * cursior methods that raise an exception if connection is async:
     * execute if another execute is underway
     * same for callproc
     * executemany
     * scroll
     * calling fetch before the query ended results in an error (not 
sure about that one, though, might be better to block)
     * copy_{from, to, expert) (might become supported later)

I don't really mind making these error out instead of trying to make 
them work, even if they'd have to block. If I'm to use it, it will be 
via a Twisted wrapper, that will present me with a different API that 
will take care of not allowing multiple executes and will not have 
things like scroll etc.

Cheers,
Jan
_______________________________________________
Psycopg mailing list
[email protected]
http://lists.initd.org/mailman/listinfo/psycopg