Bojan:
Nice. Do you want me to do a prototype patch or do you have something
already?
Thanks! Alas, I have nada in the way of an implementation; I'm
still trying to finish up my scoreboard/slow child_init/etc. fixes
for httpd. I've also been away from the keyboard much of the previous
Jut a small comment, if you do go ahead with the flag and not add a
rollback funciton (which I think is much cleaner) then please be aware
that the caller will need to know if the result was successful commit,
successful rollback, or some other failure.
Chris Darroch wrote:
Bojan:
Quoting Chris Darroch [EMAIL PROTECTED]:
So, like this:
switch (trans-mode) {
case APR_DBD_TRANSACTION_COMMIT:
res = PQexec(trans-handle-conn, COMMIT);
break;
case APR_DBD_TRANSACTION_COMMIT_ON_SUCCESS:
if (trans-errnum) {
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
Jut a small comment, if you do go ahead with the flag and not add a
rollback funciton (which I think is much cleaner) then please be aware
that the caller will need to know if the result was successful commit,
successful rollback, or some other failure.
On Sunday 30 April 2006 23:05, Chris Darroch wrote:
OK, I started working on this (skeleton of of the patch is ready), but
before I go any further, could you give me a hint on the semantics of
the above. What I'm not getting is APR_DBD_TRANS_COMMIT v.
APR_DBD_TRANS_COMMIT_ON_SUCCESS.
Bojan:
By far the most important piece of software that uses APR 1.2.x is
Apache 2.2 and associated modules. An upgrade of APR to 2.x there would
most likely require an MMN bump. I'm not sure if Apache development
policies permit this any more mid minor version. However, using APR
1.3.x,
On Sat, 2006-04-29 at 10:02 -0400, Chris Darroch wrote:
Otherwise, a nested function that wants to force a rollback
has to either do so, and then signal to all the callers that
the transaction is dead (and they then have to handle that
condition), or it has to set some internal application
On Sat, 2006-04-29 at 10:02 -0400, Chris Darroch wrote:
#define APR_DBD_TRANS_COMMIT_ON_SUCCESS 0
#define APR_DBD_TRANS_COMMIT 1
#define APR_DBD_TRANS_ROLLBACK2
#define APR_DBD_TRANS_DEFAULT APR_DBD_TRANS_COMMIT_ON_SUCCESS
OK, I started working on this
On Friday 28 April 2006 05:57, Bojan Smojver wrote:
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
Hmmm. Not too keen on this.
The original logic of APR end transaction is that it'll commit a
successful transaction otr rollback one where an error
On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote:
What's missing is the option to rollback even when successful.
In principle, a rollback argument to transaction_end would be
a better way to accomplish this. What level of version bump would
we need to introduce that?
Given that this would
Bojan:
On Fri, 2006-04-28 at 10:31 +0100, Nick Kew wrote:
What's missing is the option to rollback even when successful.
In principle, a rollback argument to transaction_end would be
a better way to accomplish this. What level of version bump would
we need to introduce that?
Given that
In my opinion two separate functions, one for commit and one for
rollback will be better and produce more readable code for the
application. I am not aware of a single DB API out there that combines
these two operations into one function. This does not mean it does not
exist of-course, however
To add to that, the logic of ANY commit operation not just APR's
end_transaction() is to commit a successful transaciton and rollback if
an error occurs. This is what commit does by definition and it has
nothing to do with an applicative decision to rollback the transaction
which happens in
On Fri, 2006-04-28 at 09:41 -0400, Chris Darroch wrote:
Now I'm partly assuming that there can't be zillions of users
yet relying on it in a 1.3 environment who really also need a
forceable rollback feature, and that those who do can upgrade to
2.x. (After all, isn't it good to provide
Quoting Bojan Smojver [EMAIL PROTECTED]:
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
OOPS! Before rollback in SQLite2/3, we need to make sure we blow away
error codes, or the query won't run. Hopefully better patch attached.
--
Bojan
Index:
Quoting Bojan Smojver [EMAIL PROTECTED]:
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
For folks using MySQL...
--
Bojan
--- apr_dbd_mysql.c.orig 2006-04-28 15:24:56.0 +1000
+++ apr_dbd_mysql.c 2006-04-28 15:24:37.0 +1000
@@
16 matches
Mail list logo
