apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject apr_dbd
Date Wed, 03 Aug 2005 16:43:59 GMT
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.

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.

-- 
Nick Kew

Mime
View raw message