Bojan Smojver wrote:
Here is the patch along the lines of setting the modes of the
transaction. It doesn't have force commit, but if the list decides
that it's the right thing to do, I'll rework. I didn't test this -
it's just a prototype. A patch for folks using MySQL is included as
On Monday 01 May 2006 16:47, Chris Darroch wrote:
Nick Kew wrote:
There's rather more than that: after any failed operation within
a transaction, apr_dbd assumes transaction failure and declines
to attempt any further ops, without reference to the backend.
I think perhaps we should
Nick:
Bojan's proposed patch (or some variant on it) will set transaction mode.
How about if we add a further APR_DBD_TRANSACTION_CLEARERR flag
(to be ORed with the mode) that'll let the application clear an error.
Drivers could reset the application state and make any corresponding
calls to
On Mon, 2006-05-01 at 14:11 -0400, Chris Darroch wrote:
Sounds good -- if you see an error you can handle, you clear
the transaction's error state back to ok, and apr_dbd lets you
proceed. Seems very reasonable to me; thanks!
Perhaps. However, it would seem that not all databases behave
On Mon, 2006-05-01 at 12:41 -0700, Tyler MacDonald wrote:
Maybe if MySQL is detected APR should refuse to support
transactions and tell the end user to find a non-broken database engine. :-)
He, he... Something like this:
#define APR_EGOFINDOTHERDB 9
--
Bojan
On Monday 01 May 2006 20:50, Bojan Smojver wrote:
On Mon, 2006-05-01 at 12:41 -0700, Tyler MacDonald wrote:
huh? Not in my mailbox, nor at marc.theaimsgroup.com ...
Maybe if MySQL is detected APR should refuse to support
transactions and tell the end user to find a non-broken database
Nick Kew [EMAIL PROTECTED] wrote:
On Monday 01 May 2006 20:50, Bojan Smojver wrote:
On Mon, 2006-05-01 at 12:41 -0700, Tyler MacDonald wrote:
huh? Not in my mailbox, nor at marc.theaimsgroup.com ...
I'll forward it. I accidentally sent it from my work email
[EMAIL PROTECTED] so it's
Here's the message that wsa sent from the wrong address:
- Forwarded message from Tyler MacDonald [EMAIL PROTECTED] -
From: Tyler MacDonald [EMAIL PROTECTED]
To: Bojan Smojver [EMAIL PROTECTED]
Cc: dev@apr.apache.org
Subject: Re: [PATCH]: Introduce APR DBD transaction mode
Bojan Smojver
Bojan Smojver [EMAIL PROTECTED] wrote:
Perhaps. However, it would seem that not all databases behave the same
on error mid-transaction. Compare SQLite3 with PostgreSQL:
SQLite3's transactions leave a bit to be desired.. and on that note,
be very, very wary of MySQL as well. It allows a
On Monday 01 May 2006 02:28, Bojan Smojver wrote:
Here is the patch along the lines of setting the modes of the
transaction. It doesn't have force commit, but if the list decides
that it's the right thing to do, I'll rework. I didn't test this -
it's just a prototype. A patch for folks using
Quoting Bojan Smojver [EMAIL PROTECTED]:
Not sure what Oracle does - I can check when I get
to work later on (but I'm guessing it would be similar to PostgreSQL).
Actually, Oracle will commit even if there were errors. So, the
situation is that for PostgreSQL, resetting the transaction
Quoting Nick Kew [EMAIL PROTECTED]:
static int dbd_foo_transaction_mode(apr_dbd_transaction_t *trans,
int flags)
{
int ret = 0
int mode = flags APR_DBD_TRANSACTION_MODEBITS;
switch (flags) {
^
On Tuesday 02 May 2006 00:53, Bojan Smojver wrote:
I'm guessing foo_clearerror() is a database specific function for
clearing errors, if such a beast exists.
Yep.
If not, user gets back
APR_ENOTIMPL status and the whole transaction must be rolled back.
Erm, no. It it doesn't exist, that
Quoting Nick Kew [EMAIL PROTECTED]:
Erm, no. It it doesn't exist, that reduces to resetting trans-errnum.
Ah, yes. Sorry. I meant we return APR_ENOTIMPL if the database cannot
possibly support resetting of trans-errnum correctly (such as PGSQL).
Otherwise, we just reset (i.e. SQLite,
Quoting Bojan Smojver [EMAIL PROTECTED]:
Databases that don't support such functionality (e.g. PostgreSQL)
would simply return APR_ENOTIMPL.
Actually, I take this bit back. We *always* reset trans-errnum, just
like Nick said (even when there is no foo_clearerr()). And this to be
able to
Quoting Bojan Smojver [EMAIL PROTECTED]:
Something like this:
Attached example patches.
--
Bojan
Index: include/apr_dbd.h
===
--- include/apr_dbd.h (revision 398759)
+++ include/apr_dbd.h (working copy)
@@ -153,6 +153,38 @@
Here is the patch along the lines of setting the modes of the
transaction. It doesn't have force commit, but if the list decides
that it's the right thing to do, I'll rework. I didn't test this -
it's just a prototype. A patch for folks using MySQL is included as
well.
--
Bojan
Index:
Quoting Bojan Smojver [EMAIL PROTECTED]:
A patch for folks using MySQL is included as well.
Sorry about the traling comma after dbd_mysql_transaction_mode_set -
lazy cut/paste :-(
--
Bojan
18 matches
Mail list logo
