apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronen Mizrahi <ro...@tversity.com>
Subject Re: possible bug in apr_dbd_sqlite3.c
Date Fri, 16 Sep 2005 23:15:19 GMT
Yes, I meant query and not select. I ended up doing exactly what you 
suggest, i.e. ignore the start and end transaction altogether. Yet, IMHO 
a DB api that has transactions is conceptually incomplete without the 
possibility to roll back, I mean how can the application writer enjoy 
the atomicity offered by the database without it? and if no atomicity is 
possible, why use transactions?
While it is of-course important to rollback a transaction when an error 
condition occurs in the DB (or DB driver), the far more common situation 
for rollback is to have errors in the application level, of which the DB 
and the DB driver know nothing of (and should know nothing), this is why 
I was saying before that apr_dbd is a conceptually incomplete interface 
with regard to transactions. I love the simplicity of the interface and 
I think it should be maintained, but ending up with a conceptually 
incomplete interface is not the right thing to do. I think there are 
only two possibilities to fix this, either apr_dbd_transaction is 
removed or the ability to roll back is added.

Nick Kew wrote:

>On Friday 16 September 2005 19:55, Ronen Mizrahi wrote:
>>Thank you for responding.
>>May I ask also a question about the apr_dbd interface and how it should
>>be used with sqlite in order to roll back a transaction. I was looking
>>for a way to rollback a transaction, and it looks like the interface
>>right now allows one to start a transaction and to commit it but it does
>>not allow one to roll it back. I ended up using apr_dbd_select() with an
>>SQL string of "ROLLBACK",
>Erm, presumably you mean query rather than select?
>>is this how the interface intends for users to 
>>do it?
>Yes.  It's a simple interface, leaving you the option to use SQL or 
>native-C-API to extend it where necessary.  If your application wants
>rollback in cases other than an error condition, you should probably
>ignore apr_dbd_transaction and do it yourself.  Doing it with
>apr_dbd_query and SQL commands should be portable across most
>>Should there perhaps be function in apr_dbd for rollback? 
>It's a thought for future versions: maybe end_transaction could have
>a parameter to indicate commit or rollback.  But API changes that break
>back-compatibility will be treated with caution, and can only happen in
>a major version change.

View raw message