From dev-return-14769-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Sep 16 23:15:30 2005
Return-Path:
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: (qmail 23985 invoked from network); 16 Sep 2005 23:15:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 16 Sep 2005 23:15:30 -0000
Received: (qmail 84910 invoked by uid 500); 16 Sep 2005 23:15:28 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 84863 invoked by uid 500); 16 Sep 2005 23:15:28 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post:
List-Help:
List-Unsubscribe:
List-Id:
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 84843 invoked by uid 99); 16 Sep 2005 23:15:28 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Sep 2005 16:15:28 -0700
X-ASF-Spam-Status: No, hits=1.0 required=10.0
tests=SPF_HELO_SOFTFAIL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [167.206.4.200] (HELO mta5.srv.hcvlny.cv.net) (167.206.4.200)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Sep 2005 16:15:37 -0700
Received: from [192.168.1.101] (ool-43516080.dyn.optonline.net [67.81.96.128])
by mta5.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-2.06 (built May 11 2005))
with ESMTP id <0IMX00GFGN9MIM00@mta5.srv.hcvlny.cv.net> for
dev@apr.apache.org; Fri, 16 Sep 2005 19:15:23 -0400 (EDT)
Date: Fri, 16 Sep 2005 19:15:19 -0400
From: Ronen Mizrahi
Subject: Re: possible bug in apr_dbd_sqlite3.c
In-reply-to: <200509162339.37648.nick@webthing.com>
To: dev@apr.apache.org
Reply-to: ronen@tversity.com
Message-id: <432B5207.6060902@tversity.com>
Organization: TVersity
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: <20050916174425.82185.qmail@web30001.mail.mud.yahoo.com>
<432B1539.4080809@tversity.com> <200509162339.37648.nick@webthing.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
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
>backends:-)
>
>
>
>>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.
>
>
>