Re: Async branch documentation and review

On 10/04/10 12:46, Federico Di Gregorio wrote:
> On 09/04/2010 21:16, Jan Urbański wrote:
> [snip]
>>> Do we really need cursor.poll()? There can only be a single async
>>> cursor in execution per connection. On the other side we can't do
>>> without connection.poll() because is using during connection, when
>>> there is no cursor. What about dropping cursor.poll() and only leave
>>> connection.poll()? If an app only had a reference to the cursor it
>>> would always be possible to call curs.connection.poll().
>>
>> I don't mind having only connection.poll, although it feels a bit
>> strange to me. If we go that way it's one step short of having (in async
>> mode) only connection.execute() and getting rid of the cursors
>> whatsoever (which is not necessarily bad).
>> Another thing is that if/when we start supporting async named cursors,
>> we might need to still call something on the cursor (haven't thought
>> about the interface yet).
>
> This is plain wrong. You still need cursors to keep multiple result sets
> around, so .execute() on the cursor should not go away.

Ah, yeah, I keep on forgetting that.

>>> I just discovered another quirk in having a cursor.poll() while the
>>> responsibility of the communication state really belongs to the
>>> connection: cursors can steal results each other:
>>
>> :( Yeah, that kind of sucks. Could this fall in the category of "so
>> don't do it"? Or should we add an exception when you try to poll() a
>> cursor that's not the one currently executing?
>
> There should be an exception.

OK, will fix.

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