Re: improving async support in psycopg

On 30/03/2010 00:17, Jan Urbański wrote:
[snip]
> 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()

That was also my initial idea. But more I think about it more I feel
that async code should be _completely_ async and the client code should
cope with it (and get loud exceptions in case of errors).

> 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

Agreed.

>     * named cursor creation

Initially. In the future I'd like to have support for async server-side
cursors too.

>   * cursior methods that raise an exception if connection is async:
>     * execute if another execute is underway
>     * same for callproc
>     * executemany

Agreed.

>     * scroll

scroll() should raise an exception only if the cursor is in the middle
of a query. If all data has been fetched then scroll should keep its
currrent behaviour.

>     * calling fetch before the query ended results in an error (not sure
> about that one, though, might be better to block)

I'd like it to raise.

>     * copy_{from, to, expert) (might become supported later)

Agreed.

> 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.

During the next few days I'll start pulling from your tree. I won't pull
any change that does non-trivial changes to the current code base but
everything that add a different code path is ok. I'll post on this list
as I progress.

Thank you very much for your contribution,

federico

-- 
Federico Di Gregorio                                       fog-NGVKUo/i/[email protected]
 Come sai se il primo è ben dato? In realtà è "Beh il secondo bacio ben
  dato non si rifiuta".                                    -- Alessandra

_______________________________________________
Psycopg mailing list
Psycopg-IAPFreCvJWPBWskQ1e/[email protected]
http://lists.initd.org/mailman/listinfo/psycopg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkux+fgACgkQvcCgrgZGjeu9IwCeNWgxMIlcgmcVQC4PRT9FD6ID
IYUAoMdVoazBAOIvfmX8Ur/1LrABWqs8
=+i6H
-----END PGP SIGNATURE-----