apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: DBD: Prepared statements, BLOBs etc.
Date Mon, 25 Sep 2006 20:59:46 GMT
On Mon, 2006-09-25 at 11:28 -0700, Chris Darroch wrote:

>    I guess my remaining hestitation relates to the fact that there's
> a lot of reliance on atoi() and friends here, and that with certain
> drivers you might see numeric data converted from the DB's internal
> format to a string (because the driver asks for string data values),
> using the DB's internal conversion mechanism, and then converted
> back to a numeric value by atoi(), apr_atoi64(), etc. because the
> caller asked the driver for a specific numeric format.  I'm not a
> floating-point expert, I confess ... could there be subtle data
> conversion problems lurking in there?
> 
>    OTOH, if all the drivers work the same way and all use atoi()
> and friends, then any variations between drivers in extracting some
> known floating-point value from the DBs would have to be caused
> by the DBs' internal conversions to strings ... does that let APR
> off the hook?  I just don't know, myself.

The proper thing to do would be to get a float/int/double etc. directly
from the SQL backend if at all possible to minimise conversion problems.
We can always work on that later, as it is an implementation detail and
it shouldn't affect how API works.

Obviously, some of the functions would have to be changed internally to
facilitate the fact that we'd have all kinds of different data fetched
from the backend. I just didn't want to complicate things too much with
the first iteration. Also, present code does strings only, so we should
not be worse off by doing conversions, as we have to do them now after
calling get_entry().

In fact, since I didn't do any work with Oracle driver, you can
implement that approach there from the word go :-).

>    I'm not really sure what's best here.  Because these structures
> for LOB data will necessarily vary across drivers, my hestitation
> remains about putting the structure definition right in apr_dbd.h.
> I *think* that appending fields to structures might be permitted across
> minor version changes, without breaking the ABI, but I'm not 100% sure.
> That might suffice to handle any new fields required by support for
> additional data types and/or databases in the future.  But I'd feel
> better if an API/ABI rules guru weighed in on that.  :-)

Yeah, it would be good if someone else chimed in. However, we can always
go opaque and make sure nobody relies on this structure being certain
way. Then we'd have:

apr_dbd_blob_data_set/get()
apr_dbd_blob_length_set/get()
apr_dbd_blob_table_set/get()
apr_dbd_blob_column_set/get()
...

And our structure would always be "compatible". This is not a
complicated thing to implement at all and if that's preferred, I can
work on it.

-- 
Bojan


Mime
View raw message