Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #102121

Re: Question about asyncio and blocking operations

From "Frank Millman" <frank@chagford.com>
Newsgroups comp.lang.python
Subject Re: Question about asyncio and blocking operations
Date 2016-01-26 16:15 +0200
Message-ID <mailman.11.1453820010.2338.python-list@python.org> (permalink)
References <n8038j$575$1@ger.gmane.org>

Show all headers | View raw


"Frank Millman"  wrote in message news:n8038j$575$1@ger.gmane.org...
>
> I am developing a typical accounting/business application which involves a 
> front-end allowing clients to access the system, a back-end connecting to 
> a database, and a middle layer that glues it all together.
>
[...]
>
> There was one aspect that I deliberately ignored at that stage. I did not 
> change the database access to an asyncio approach, so all reading 
> from/writing to the database involved a blocking operation. I am now ready 
> to tackle that.

I am making some progress, but I have found a snag - possibly unavoidable, 
but worth a mention.

Usually when I retrieve rows from a database I iterate over the cursor -

    def get_rows(sql, params):
        cur.execute(sql, params)
        for row in cur:
            yield row

If I create a Future to run get_rows(), I have to 'return' the result so 
that the caller can access it by calling future.result().

If I return the cursor, I can iterate over it, but isn't this a blocking 
operation? As far as I know, the DB adaptor will only actually retrieve the 
row when requested.

If I am right, I should call fetchall() while inside get_rows(), and return 
all the rows as a list.

This seems to be swapping one bit of asynchronicity for another.

Does this sound right?

Frank

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Question about asyncio and blocking operations "Frank Millman" <frank@chagford.com> - 2016-01-26 16:15 +0200

csiph-web