Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F33EDDC55 for ; Wed, 12 Sep 2012 08:24:30 +0000 (UTC) Received: (qmail 76621 invoked by uid 500); 12 Sep 2012 08:24:30 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 76450 invoked by uid 500); 12 Sep 2012 08:24:26 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 76407 invoked by uid 99); 12 Sep 2012 08:24:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 08:24:24 +0000 X-ASF-Spam-Status: No, hits=-1.6 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.1.208] (HELO exprod6og107.obsmtp.com) (64.18.1.208) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Sep 2012 08:24:15 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUFBGmalw/61SI8QhEnvuPX9aT7+gB33F@postini.com; Wed, 12 Sep 2012 01:23:54 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q8C8NlEa021894 for ; Wed, 12 Sep 2012 01:23:52 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q8C8NkYr010163 for ; Wed, 12 Sep 2012 01:23:46 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 12 Sep 2012 01:23:45 -0700 Received: from susi.local (10.136.128.195) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.264.0; Wed, 12 Sep 2012 09:23:44 +0100 Message-ID: <50504691.3010803@apache.org> Date: Wed, 12 Sep 2012 09:23:45 +0100 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Subject: Re: The infamous getSize() == -1 (Was: [jira] [Created] (OAK-300) Query: QueryResult.getRows().getSize()) References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi, On 11.9.12 11:08, Jukka Zitting wrote: > > Instead I'd propose the following design: > > * The getSize() method always returns the size, by buffering all > results in memory if necessary. > * A separate hasSize() method can be used to check if the size is > quickly available (i.e. if getSize() will complete in O(1) time). > As an alternative: we could use a separate method getSize(int max) which * if called with max == -1 returns the exact size if quickly available, * returns -1 otherwise, and * returns the exact size but not more then max when called with max >= 0. This allows for estimates but leaves the caller in control. Michael