apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: apr_dbd
Date Tue, 09 Aug 2005 18:27:23 GMT
Nick Kew wrote:

> 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.
> 

Can we really do that?  Adding an entry to the end of the 
apr_dbd_driver_t struct will change its size, and it's defined in a 
public header file, so I think that might be against our versioning 
guidelines, strictly speaking...

-garrett

Mime
View raw message