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 Tue, 17 May 2005 15:04:13 GMT
Nick Kew wrote:
> Paul Querna wrote:
> 
>>Garrett Rooney wrote:
>>
>>
>>>Nick Kew wrote:
> 
> 
>>>>However, we have what now appears to be a redundant argument:
> 
> 
> 
>>>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.
> 
> 
> I'm not convinced by that.  Moving the "current" transaction to the
> apr_dbd_t for all other purposes seems to go against that, and having
> a separate transaction in one place only seems an open invitation
> to ambiguity and bugs.  Besides, a driver can choose to implement
> recursive transactions by (say) putting a stack of them within its
> definition of apr_dbd_t.

Yes, but unless the user had access to the transaction objects they 
wouldn't have any way to say "roll back the second to last transaction", 
they'd be limited to interacting with the most recent one.  That's why 
it would have to be in the API.  That said, I suspect it just doesn't 
matter all that much, and that like you and Paul already said anyone who 
cares about such things can just do it via SQL directly, since it seems 
rather database specific anyway.

-garrett

Mime
View raw message