apr_dbd transactions API

[Garrett Rooney <ro...@electricjellyfish.net>]

I'm wondering if the way transactions fit into the current API makes 
sense...  Currently we've got a transaction argument that gets passed 
into each function that calls into the database.  In the postgres impl 
all it seems to do is store an error value, which is used to bail out in 
the case where an error has already occurred.  Is it really necessary to 
make this separate?  Why not just include the transaction as part of the 
dbd object itself, so it doesn't have to be passed into each and every 
function?  Are we trying to support multiple nested transactions or 
something?  Is that really worthwhile?  Even if it is, it could be 
handled inside the dbd instead of outside it with a simple stack...

-garrett

Re: apr_dbd transactions API

[Nick Kew <ni...@webthing.com>]

On Friday 04 February 2005 15:49, Garrett Rooney wrote:

> If you don't have any objection I'll look at pulling it out of the API
> and into the dbd object this weekend.

Fine with me.  It's not going to hit the top of my own to-do list in
that time, anyway:-)

-- 
Nick Kew

Re: apr_dbd transactions API

[Garrett Rooney <ro...@electricjellyfish.net>]

Nick Kew wrote:
> On Thursday 03 February 2005 00:46, Garrett Rooney wrote:
> 
>>I'm wondering if the way transactions fit into the current API makes
>>sense...  Currently we've got a transaction argument that gets passed
>>into each function that calls into the database.  In the postgres impl
>>all it seems to do is store an error value, which is used to bail out in
>>the case where an error has already occurred.
> 
> 
> It's essentially the same in the MySQL driver.  It would certainly be possible
> to leave it to implementations to store the transaction in the dbd object.
> In fact you're probably right: the transaction API has already changed once
> in response to someone's suggestion on this list, and is looking a bit
> awkward - no doubt because I made the most obvious change rather than
> the best.

If you don't have any objection I'll look at pulling it out of the API 
and into the dbd object this weekend.

-garrett

Re: apr_dbd transactions API

[Nick Kew <ni...@webthing.com>]

On Thursday 03 February 2005 00:46, Garrett Rooney wrote:
> I'm wondering if the way transactions fit into the current API makes
> sense...  Currently we've got a transaction argument that gets passed
> into each function that calls into the database.  In the postgres impl
> all it seems to do is store an error value, which is used to bail out in
> the case where an error has already occurred.

It's essentially the same in the MySQL driver.  It would certainly be possible
to leave it to implementations to store the transaction in the dbd object.
In fact you're probably right: the transaction API has already changed once
in response to someone's suggestion on this list, and is looking a bit
awkward - no doubt because I made the most obvious change rather than
the best.


-- 
Nick Kew