apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: apr_dbd transactions
Date Mon, 16 May 2005 18:32:11 GMT
Garrett Rooney wrote:
> 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.

PostgreSQL does with Savepoints:
http://www.postgresql.org/docs/8.0/interactive/sql-savepoint.html

But, most people will want to control these directly with an SQL
statement, rather than inside the API, imho.

-Paul



Mime
View raw message