Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Michael Torrie <torriem@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Cannot step through asynchronous iterator manually
Date: Sat, 30 Jan 2016 14:57:59 -0700
Lines: 20
Message-ID: <mailman.140.1454191090.2338.python-list@python.org>
References: <n8hjmt$b8n$1@ger.gmane.org> <CALwzid=sSDSm8hdAN+ORJ54A_jEu9Wc8103iqGKAah8mrj-TXw@mail.gmail.com> <n8hrs1$orn$1@ger.gmane.org> <56AD122F.2030904@gmail.com> <CAPTjJmpGFbnOJGTQcYcFQK83HGCoH5td57J7+RpM_tsR=O3ZOA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de hfoM/QHolkVQmji5XXl8sg09c+NVkW64aZR1MQfQEmQA==
Return-Path: <torriem+gmail@torriefamily.org>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.005
X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'alias': 0.07; 'column': 0.07; 'exception.': 0.07; 'fetch': 0.09; 'throw': 0.09; 'result.': 0.15; 'count,': 0.16; 'from:addr:torriem': 0.16; 'from:name:michael torrie': 0.16; 'query.': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'row': 0.16; 'succeeds,': 0.16; 'wrote:': 0.16; 'result,': 0.18; 'algorithm': 0.20; 'not,': 0.22; 'occurs': 0.22; 'decide': 0.23; 'select': 0.23; '(or': 0.23; 'second': 0.24; 'header:In-Reply-To:1': 0.24; 'header:User- Agent:1': 0.26; "doesn't": 0.26; 'rest': 0.26; 'chris': 0.26; 'there.': 0.30; 'query': 0.30; 'another': 0.32; 'run': 0.33; 'true.': 0.33; 'message-id:@gmail.com': 0.34; 'done': 0.35; 'to:addr:python-list': 0.36; 'pm,': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'received:org': 0.37; 'whatever': 0.39; 'received:192': 0.39; 'to:addr:python.org': 0.40; 'where': 0.40; 'still': 0.40; 'your': 0.60; 'charset:windows-1252': 0.62; 'matter': 0.63; 'is.': 0.63; 'more': 0.63; 'information': 0.63; 'wish': 0.71; 'results,': 0.91
X-Virus-Scanned: amavisd-new at torriefamily.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
In-Reply-To: <CAPTjJmpGFbnOJGTQcYcFQK83HGCoH5td57J7+RpM_tsR=O3ZOA@mail.gmail.com>
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.20+
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Xref: csiph.com comp.lang.python:102314

On 01/30/2016 02:19 PM, Chris Angelico wrote:
> where the ... is the full original query. In other words, the whole
> query has to be run twice - once to assert that there's exactly one
> result, and then a second time to get that result. The existing
> algorithm ("try to fetch a row - if it fails error; then try to fetch
> another - if it succeeds, error") doesn't need to fetch more than two
> results, no matter how big the query result is.

Actually it occurs to me this doesn't have to be true.  The same
information he needs to know can be done with one query and only 1 result.

SELECT count(some_id_field),field1,field2,field3 FROM wherever WHERE
conditions

If the first column (or whatever you decide to alias it as) contains a
count, and the rest of the information is still there.  If count is 1,
then the row is what you want and you can do whatever you wish with it.
 If not, throw your exception.