apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vandenberg <jay...@gmail.com>
Subject Re: apr_dbd
Date Wed, 03 Aug 2005 22:18:06 GMT
On 8/4/05, Nick Kew <nick@webthing.com> wrote:

Hi Nick,

> As indicated in my post of a few weeks ago, I'd like to support typed
> data in apr_dbd.  I posted a patch that would change (and break) the
> API.  Since apr_dbd hasn't yet featured in a release version, there was
> no absolute reason not to.

I am not familiar with the existing purpose behind the apr_dbd
interface, but it strikes me as odd that apr needs to incorporate a
complex DB abstraction layer; a simple string based layer, like libsdb
(lgpl), would suffice for most needs.

Also, if a complex layer is needed, what is the advantage of building
a new one for apr; could libdbi (libdbi) or sqlrelay be used instead?

> Since then I've given the matter some more thought, and would propose
> doing it without breaking existing code.  That way we can release
> apr_dbd as-is, and expand the API at leisure.
> 
> The changes I originally proposed were:
> 
> (1) Introduce a new apr_dbd_datum_t type, comprising a type field
>     (enum), and a value which is a union of C types.
> 
> (2) Change get_entry prototype to
> 
> /** apr_dbd_get_entry: get an entry from a row
>  *
>  *  @param driver - the driver
>  *  @param row - row pointer
>  *  @param col - entry number
>  *  @return zero for success or error
>  */
> APU_DECLARE(int) apr_dbd_get_entry(apr_dbd_driver_t *driver,
>                                    apr_dbd_row_t *row, int col,
>                                    apr_dbd_datum_t *val);
> 
> (3) Pass apr_dbd_datum_t args in the execute-prepared-statement calls.
> 
> Now, of these, (1) is just a typedef, so it doesn't break anything.
> (2) is the crux of the matter.  (3) can be dealt with by drivers
> without touching the API, leaving current behaviour as a default.
> 
> The simple fix to (2) without breaking anything is to retain the
> existing get_entry as-is, and introduce an apr_dbd_get_typed_entry
> defined as above.  That would of course be an extra entry on the
> end of the apr_dbd_driver_t struct.
> 
> A possible followup to this would be a function to set properties
> of apr_dbd objects.  This can be introduced as and when it is
> considered necessary without breaking anything.

--
John

Mime
View raw message