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
