Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of bojan@rexursive.com designates
 203.171.74.242 as permitted sender)
Subject: Re: Some dbd driver questions
From: Bojan Smojver <bojan@rexursive.com>
To: Tom.Donovan@acm.org
Cc: dev@apr.apache.org
In-Reply-To: <4605443B.5090109@bellatlantic.net>
References: <4605443B.5090109@bellatlantic.net>
Content-Type: text/plain
Date: Sun, 25 Mar 2007 08:19:29 +1000
Message-Id: <1174774769.3139.8.camel@shrek.rexursive.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sat, 2007-03-24 at 11:31 -0400, Tom Donovan wrote:

> I've been working on an ODBC dbd driver, and I have a few questions 
> about how LOBs are supposed to be returned as bucket brigades.
> 
> Looking at the Oracle driver, it appears that the caller creates the 
> brigade which is passed as an argument to apr_dbd_datum_get.
> 
> If the LOB contains no data, the Oracle driver inserts an EOS bucket 
> into the brigade, but I don't see that an EOS bucket is ever inserted 
> when when the bucket read function finally reaches the end of the data.
> 
> What is supposed to happen here?  If the caller really does pass an 
> existing brigade - shouldn't the driver presume it already has an EOS 
> bucket, as well as other kinds of data or metadata buckets in it?

The brigade should be empty, I guess. We want to store data from the
database into it. As for EOS v. no-EOS, I have to check what's actually
happening in the code. There could be bugs in there - I can't remember
what exactly I did there.

> The handling of NULL (SQL NULL values vs. "C" NULL pointers) is not 
> really clear.  I've been setting the return pointer argument to 
> _get_entry/_datum_get to NULL to indicate an SQL NULL column value for 
> other data types - but this doesn't seem like the right thing to do for 
> a pointer to an existing bucket brigade.

get_entry() doesn't understand how to distinguish between SQL NULL and
"C" NULL - don't use if for that. That's why we invented datum_get(),
which should return APR_ENOENT if SQL data is NULL. If it doesn't,
that's a bug.

> Inserting an empty bucket wouldn't distinguish between a bona-fide SQL 
> NULL and a LOB which contains zero-length data.

Have to check the code to see what's going on there. Can't remember any
more :-(

> Finally, Most of the non-binary functions have new "b"inary equivalents:
> 
>    There is a _pbselect and a _pvbselect - but not a simple _bselect.
> 
> Is it intentional that there is no un-prepared binary select, or was 
> this just an oversight?  One-shot (i.e. runtime generated SQL) 
> statements don't benefit much from being prepared and then only used 
> once.  A _bselect function would be useful.

I didn't see the need for it, as select doesn't take any parameters, so
distinction between binary and char parameters obviously doesn't make
sense. You can just use regular _select() or even _p[b]select, if you
want the non-parameter statement to be prepared. Both datum_get() and
get_entry() can be used after all any of select/p[b]select.

-- 
Bojan