apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Some dbd driver questions
Date Sat, 24 Mar 2007 22:19:29 GMT
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.


View raw message