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 transactions
Date Mon, 16 May 2005 14:44:30 GMT
Nick Kew wrote:
> The original apr_dbd implementation had transactions being
> passed to all relevant functions as apr_dbd_transaction_t*
> argument.
> 
> This was changed to make the current transaction a field
> of an apr_dbd_t, and remove the argument from functions.
> 
> However, we have what now appears to be a redundant argument:
> 
> APU_DECLARE(int) apr_dbd_transaction_start(apr_dbd_driver_t *driver,
>                                            apr_pool_t *pool,
>                                            apr_dbd_t *handle,
>                                            apr_dbd_transaction_t **trans);
> 
> Since the transaction is now a field of the handle, passing a
> separate argument seems redundant.
> 
> Did anyone have a strong reason for this, or would it make sense to
> update the prototypes to
> 
> APU_DECLARE(int) apr_dbd_transaction_start(apr_dbd_driver_t *driver,
>                                            apr_pool_t *pool,
>                                            apr_dbd_t *handle);
> 
> and perhaps also from:
> 
> APU_DECLARE(int) apr_dbd_transaction_end(apr_dbd_driver_t *driver,
>                                          apr_pool_t *pool,
>                                          apr_dbd_transaction_t *trans);
> 
> to
> 
> APU_DECLARE(int) apr_dbd_transaction_end(apr_dbd_driver_t *driver,
>                                          apr_pool_t *pool,
>                                          apr_dbd_t *handle);
> 

I think the reason I left it in the prototype was on the off chance that 
we want to be able to handle recursive transactions of some sort.  Of 
course, I have no idea if any supported databases actually allow such 
things, so it may not be worth cluttering up the codebase for it.

-garrett

Mime
View raw message