Re: improving async support in psycopg

On 28/03/10 03:35, Daniele Varrazzo wrote:
> On Sat, Mar 27, 2010 at 2:40 AM, Jan Urbański<[email protected]>  wrote:
>
>> Skimming over the patches I have a question: is it really necessary to add
>> the callback feature into the C library? AFAICS the callback is executed on
>> asynchronous cursors everytime there is a execute() attempt. Couldn't you
>> just write a Python psycopg2.extensions.cursor subclass that overrides
>> execute() by calling that callback?
>
> As things are now, execute and callproc being the only methods using
> async features, this is the case. Probably it will be too extending
> support to other currently blocking methods (begin/commit/rollback
> etc).

 From the discussion it seems that Federico would prefer to shift the 
responsability of safely using async features to the framerworks instead 
of instrumenting more psycopg methods.

OTOH I saw your post on the gevent mailing list and it indeed would be 
cool if you could change your apps to non-blocking without changing 
their code, by just dropping in the gevent module. I'm not convinced 
that's fully possible, though. I think gevent could provide connection 
and cursor subclasses that would emulate connection.commit() by issuing 
a COMMIT query and waiting (non-blockingly) for it to return. You could 
probably do the same thing for other methods and build up a fully async 
drop-in replacement that you could use with django or whatnot.

I think it makes sense to only expose the raw stuff and let frameworks 
use it the way they see fit.

All that sounds very interesting, please keep posting your results!

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