apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Rossi <bob_ro...@cox.net>
Subject Re: sqlite3 and postgresql
Date Wed, 21 May 2008 14:13:41 GMT
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

Mime
View raw message