Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Date: Wed, 21 May 2008 10:13:41 -0400
From: Bob Rossi <bob_rossi@cox.net>
Subject: Re: sqlite3 and postgresql
In-reply-to: <20080520013207.GJ19723@brasko.net>
To: Bojan Smojver <bojan@rexursive.com>, dev@apr.apache.org
Mail-followup-to: Bojan Smojver <bojan@rexursive.com>, dev@apr.apache.org
Message-id: <20080521141341.GF24464@brasko.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
References: <20080517130754.GJ6437@brasko.net>
 <1211151512.9901.35.camel@shrek.rexursive.com>
 <20080520013207.GJ19723@brasko.net>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, May 19, 2008 at 09:32:07PM -0400, Bob Rossi wrote:
> On Mon, May 19, 2008 at 08:58:32AM +1000, Bojan Smojver wrote:
> > On Sat, 2008-05-17 at 09:07 -0400, Bob Rossi wrote:
> > 
> > > I've been using sqlite3 dbd for some time now. I find that the function
> > > apr_dbd_get_row,
> > >   http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gd4cdc5f4e8981b93f5a467a8c8a768f1
> > > is 1 based. That is, 1 is the first row returned from a query. However,
> > > I just started using postgresql, and I find that apr_dbd_get_row is 0
> > > based. That is, 0 is the first row returned from the query.
> > 
> > This should now be fixed in both the trunk and 1.3.x branch.
> > 
> > We really _do_ appreciate your testing and suggestions!
> 
> I can confirm that the latest 1.3.x snapshot on linux, for both sqlite3
> and postgresql use a 1 based row index. I removed my hack, and things
> work great. I'm going to test windows now, could take some time.
> (perhaps get results tomorrow).

OK, I have confirmed 1 bug. If you pass '0' to apr_dbd_get_row, with
postgresql as the driver, the function returns 0, instead of -1 as it
should. My unit tests happen to test the cases that should fail, that's
how I caught this.

When, I do the apr_dbd_select, I pass -1 to the random variable. The
documentation says,
  - 1 to support random access to results (seek any row); 0 to support
    only looping through results in order (async access - faster) 

Now, when I do the apr_dbd_get_row, I pass in 0 as the row number.
The code in apr_dbd_pgsql.c says,
 228:     int sequential = ((rownum >= 0) && res->random) ? 0 : 1;

This returns sequential as 0, which I believe is correct. Now Here:

 230:     if (row == NULL) {
 231:         row = apr_palloc(pool, sizeof(apr_dbd_row_t));
 232:         *rowp = row;
 233:         row->res = res;
 234:         if ( sequential ) {
 235:             row->n = 0;
 236:         }
 237:         else {
 238:             if (rownum > 0) {
 239:                 row->n = --rownum;
 240:             }
 241:         }
 242:     }

my row is NULL, and I eventually get to line 238, and not to 
239, since rownum is 0. Finally, here:

254:     if (res->random) {
255:         if (row->n >= res->ntuples) {
256:             *rowp = NULL;
257:             apr_pool_cleanup_run(pool, res->res, clear_result);
258:             res->res = NULL;
259:             return -1;
260:         }
261:     }

res->random is true, so I get to line 255. However, 
then row->n >= res->ntuples is false, so I skip the rest of the if 
statement.  At this point, I immediately drop to the end of the 
function, which returns 0.

Is this enough information for you to determine where the bug is?

Thanks,
Bob Rossi