apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: apr_dbd transactions
Date Tue, 17 May 2005 09:41:40 GMT
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.

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

Exactly.  There's a limit to what we want apr_dbd to do, and application
developers can add to it where necessary.  Having any transactions at
all in apr_dbd is just a minor convenience.

-- 
Nick Kew

Mime
View raw message