Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 85153 invoked from network); 13 Apr 2005 00:13:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Apr 2005 00:13:50 -0000 Received: (qmail 25235 invoked by uid 500); 13 Apr 2005 00:13:49 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 25201 invoked by uid 500); 13 Apr 2005 00:13:48 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 25180 invoked by uid 99); 13 Apr 2005 00:13:48 -0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,FORGED_YAHOO_RCVD X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from web30008.mail.mud.yahoo.com (HELO web30008.mail.mud.yahoo.com) (68.142.200.71) by apache.org (qpsmtpd/0.28) with SMTP; Tue, 12 Apr 2005 17:13:47 -0700 Received: (qmail 9080 invoked by uid 60001); 13 Apr 2005 00:13:44 -0000 Message-ID: <20050413001344.9078.qmail@web30008.mail.mud.yahoo.com> Received: from [192.18.191.249] by web30008.mail.mud.yahoo.com via HTTP; Tue, 12 Apr 2005 17:13:44 PDT Date: Tue, 12 Apr 2005 17:13:44 -0700 (PDT) From: Rick Keiner Subject: Re: apr_dbd To: Nick Kew , dev@apr.apache.org Cc: Rick Keiner In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --- Nick Kew wrote: > Rick Keiner wrote: > > Here is some work I've done on the SQLite driver > for > > apr_dbd. It's based on the work Ryan Phillips had > > done. > > Thanks for reminding me: I've been meaning to look > at Ryan's patch, > but round tuits have been very difficult (illness > followed by house > move). > > I notice this is sqlite3, whereas sqlite2 is in svn > ... ?? Ryan had built a driver for sqlite3 initially. He then changed the driver to sqlite2 since that was his immediate requirement. I picked up the initial work he had done on sqlite3 and modified that code. > > > I've changed the select to build a linked list > > of the result set so that the number of tuples > will be > > correct. The subsequent get rows retrieve the data > > from the linked list. This works only if there is > one > > select in the query. > > Was that solely to implement the NOTIMPL functions, > or have > you made other changes? No and yes. The NOTIMPL functions remain NOTIMPL. I changed the dbd_sqlite3_select code to build a linked list of the result set so dbd_sqlite3_num_tuples returned a correct value. The subsequent dbd_sqlite3_get_row functions return the results from the linked list. > > > I have a general question about the query How > should > > the results be returned if there are multiple > selects > > in the query? Should it just return an array of > > apr_results_t *. > > Can you give an example of what you mean? You may > be going > beyond the scope of what apr_dbd is designed for, in > which case > we need to decide whether it's important enough to > merit a > review of the existing API. The question stems from the capability in SQLite to pass multiple queries in a semi-colon seperated string when calling sqlite3_prepare. This a nice feature that was implemented, by Ryan, in the dbd_sqlite3_query. I know there's no specification for it with the apr_dbd but there's nothing preventing it, either. Which is fine for the queries where there is no result set. Sort of. For example, there's no mechanism for handling the error return from subsequent sqlite3_step's and indicating which statement in the string caused the error. One fails, all fail, maybe. For queries that return a result set the issues are much more complicated. What to do when a query fails, asynchronous vs. synchronous, mixed queries with and without result sets, etc. Given the fact that the return from the apr_dbd_select is a apr_dbd_results_t pointer that indicates a single result set from a single select. To do otherwise could be very problematic. I was just asking to see if there were other takes on the issue. > > -- > Nick Kew >