I'm not sure if this list is the correct place to ask this question, given it's
the APR development list, but I'll take my chances...
I'm trying to figure out how to get a file descriptor (integer or FILE*) out of
the apr_file_t. Is there a function to do that?
Part of my application, that is
Thanks Cliff. You saved the day... :-)
On Thu, 2003-08-14 at 17:49, Cliff Woolley wrote:
On Thu, 14 Aug 2003, Bojan Smojver wrote:
I'm not sure if this list is the correct place to ask this question,
given it's the APR development list, but I'll take my chances...
Definitely the right
Thanks guys for clarifying that further.
The thing that I'm building with APR is an Apache 2 module plus apps that run in
conjunction with that module, so in theory it might even be used by someone
under Windows. I personally don't care about Windows - as long as it works on
Linux and Unix, I'm
You can put mod_spin on the list of open source projects using APR. The
URL for it is here:
http://www.rexursive.com/software/modspin.html
--
Bojan
Does APR support binding, polling, connecting etc. to Unix domain sockets? I
have looked into Doxygen documentation and header files, but was unable to find
anything that would be the UNIX equivalent of APR_INET...
One other thing, related to the API docs on the web site. They appear to be
rather
You can put on the list of projects using APR my own mod_spin
(http://www.rexursive.com/software/modspin/). Not only does the module
use APR, but also the applications written for it use APR. Also, the API
that the module provides relies heavily on APR.
This module is licensed under the GPL, so
Thanks.
On Thu, 2003-12-18 at 11:27, Cliff Woolley wrote:
On Thu, 18 Dec 2003, Bojan Smojver wrote:
You can put on the list of projects using APR my own mod_spin
(http://www.rexursive.com/software/modspin/). Not only does the module
use APR, but also the applications written for it use
There is a number of projects that use APR/APU now and many of them
could use Doxygen tag files to reference APR/APU APIs. So, here are two
patches for doxygen.conf files in each repository.
--
Bojan
--- doxygen.conf-vanilla 2004-06-29 09:48:26.700425000 +1000
+++ doxygen.conf 2004-06-29
I'm not entirely sure if there is some reason (unknown to me) for not
putting apr_dbd into its own doxygen documentation module, but
nevertheless, here is the patch that attempts to do that.
--
Bojan
diff -rauN apr-util-vanilla/include/apr_dbd.h apr-util/include/apr_dbd.h
---
Had a look at that function and as per documentation, it should be
called only once. This all works fine if one Apache module (e.g.
mod_dbd) is the only module calling this function. However, if two
modules (which don't necessarily know about each other) attempt to call
this function, the whole
On Mon, 2006-02-13 at 10:52 +, Nick Kew wrote:
FWIW, we have an uncommitted patch that looks like this.
Feel free to improve it.
Thanks. I'll work on the underlying drivers in order to get this going.
Any comments in relation to apr_dbd_init situation (my other e-mail)?
--
Bojan
Quoting Nick Kew [EMAIL PROTECTED]:
It'll have to wait for 1.3, 'cos it affects the API (despite not breaking
anything:-)
That's cool. Whoever (that would be me :-) wants the column names will
be able to patch their own copy of APR before the 1.3 release.
I think we should fix it by
Starting with the easiest native API, here is the PostgreSQL version of
that get_name patch.
--
Bojan
diff -rauN apr-util-vanilla/dbd/apr_dbd_pgsql.c apr-util/dbd/apr_dbd_pgsql.c
--- apr-util-vanilla/dbd/apr_dbd_pgsql.c 2005-11-29 10:31:28.0 +1100
+++ apr-util/dbd/apr_dbd_pgsql.c
Here is a stab at sqlite2.
--
Bojan
diff -rauN apr-util-vanilla/dbd/apr_dbd_sqlite2.c apr-util/dbd/apr_dbd_sqlite2.c
--- apr-util-vanilla/dbd/apr_dbd_sqlite2.c 2006-01-27 16:15:48.0 +1100
+++ apr-util/dbd/apr_dbd_sqlite2.c 2006-02-14 16:28:25.0 +1100
@@ -114,6 +114,15 @@
And the same thing for sqlite3.
--
Bojan
diff -rauN apr-util-vanilla/dbd/apr_dbd_sqlite3.c apr-util/dbd/apr_dbd_sqlite3.c
--- apr-util-vanilla/dbd/apr_dbd_sqlite3.c 2006-01-27 16:15:48.0 +1100
+++ apr-util/dbd/apr_dbd_sqlite3.c 2006-02-14 16:30:14.0 +1100
@@ -177,6 +177,15 @@
This is required for the function to exist within the internal structure.
--
Bojan
diff -rauN apr-util-vanilla/include/private/apr_dbd_internal.h apr-util/include/private/apr_dbd_internal.h
--- apr-util-vanilla/include/private/apr_dbd_internal.h 2005-10-15 14:24:51.0 +1000
+++
I can verify that the patches for column names compile on my box
(Fedora Core 4), but I haven't actually tested the code yet. Also, I
still have to work on the MySQL side of things.
Any feedback is appreciated.
--
Bojan
On Mon, 2006-02-13 at 19:54 +, Nick Kew wrote:
It'll have to wait for 1.3, 'cos it affects the API (despite not breaking
anything:-)
Actually, it just occurred to me that we could do this in a completely
backward compatible manner, with (admittedly) somewhat ugly approach. We
could modify
On Tue, 2006-02-14 at 20:09 +1100, Bojan Smojver wrote:
if (col 0)
get_name(get_result_from_row(row), -col - 1);
This should be, of course:
return get_name(get_result_from_row(row), -col - 1);
--
Bojan
I only managed to forget the most important bit :-)
--
Bojan
diff -rauN apr-util-vanilla/dbd/apr_dbd.c apr-util/dbd/apr_dbd.c
--- apr-util-vanilla/dbd/apr_dbd.c 2006-02-14 21:14:08.0 +1100
+++ apr-util/dbd/apr_dbd.c 2006-02-14 21:16:39.0 +1100
@@ -238,6 +238,11 @@
{
return
On Tue, 2006-02-14 at 04:29 -0600, William A. Rowe, Jr. wrote:
That still doesn't work, because invoking with -1 on apr 1.2.2 v.s. 1.2.4
would be broken.
You can't change the binary or functional API between subversions.
Darn! Didn't think of that one :-(
--
Bojan
I was thinking something like this for MySQL, but I haven't even
compiled this, so approach with caution.
--
Bojan
--- apr_dbd_mysql.c.vanilla 2006-02-13 17:45:20.0 +1100
+++ apr_dbd_mysql.c 2006-02-15 08:22:54.0 +1100
@@ -76,6 +76,7 @@
MYSQL_RES *res;
MYSQL_STMT
Quoting Bojan Smojver [EMAIL PROTECTED]:
I was thinking something like this for MySQL, but I haven't even
compiled this, so approach with caution.
I'm pretty sure this one will have at least one problem. The line:
return res-fields[n]-name;
should probably be:
return res-fields[n].name
Quoting DeTerra, David J [EMAIL PROTECTED]:
I was wondering if anyone would be kind enough to merge rev 233488 of
apr_dbd_sqlite3.c back into the 1.2.x branch. There is a key fix in
there to enable FLOAT support for sqlite3 queries.
Yep, that would be great.
Another question, somewhat
Quoting Nick Kew [EMAIL PROTECTED]:
+APU_DECLARE(const char*) apr_dbd_get_name(const apr_dbd_driver_t *driver,
+ apr_dbd_results_t *res, int col);
I'm having a feeling (after doing a bit of testing on this) that we
should also include a pool in the
Quoting Nick Kew [EMAIL PROTECTED]:
But async queries shouldn't be an issue here AFAICS.
Sorry, I think I wasn't specific enough. It appears to me that PGSQL
will be the one having a problem here for async queries. Basically, for
async _*select, the res-res is NULL until get_row is called.
Here is a set of (hopefully better) patches against various files in
apr_dbd code that enable the get_name support.
--
Bojan
--- include/apr_dbd.h.orig
+++ include/apr_dbd.h
@@ -210,6 +210,18 @@
APU_DECLARE(const char*) apr_dbd_get_entry(const apr_dbd_driver_t *driver,
Quoting Bojan Smojver [EMAIL PROTECTED]:
Here is a set of (hopefully better) patches against various files in
apr_dbd code that enable the get_name support.
Arrrgh! Don't you hate it when you send the wrong thing? Here is
correct PgSQL patch - no need to check for boundaries - PQfname
On Wed, 2006-02-22 at 05:51 +, Nick Kew wrote:
If a pool is needed, it should be simple enough to make it a member of the
apr_dbd_results_t struct. But since get_row at the same level of the API
has a pool argument, I agree your proposal looks like the best solution.
Actually, when I
Browsing through the code of DBD, I noticed that SQLite2/3 don't quite
do the advertised bounds checking for get_entry functions. The
following patch should be good for both 1.2.2 and the trunk.
--
Bojan
diff -rauN apr-util-1.2.2-vanilla/dbd/apr_dbd_sqlite2.c
Quoting Bojan Smojver [EMAIL PROTECTED]:
What should happen instead for SQLite3 is
apr_pstrdup of column names inside dbd_sqlite3_select (i.e. at present,
this part of the code in the driver is buggy, but since it doesn't get
used, nobody noticed yet).
More on this point - the new code should
This patch fixes memory allocation problems with column names in both
1.2.2 and trunk. It compiled fine on FC4.
--
Bojan
diff -rauN apr-util-1.2.2-vanilla/dbd/apr_dbd_sqlite3.c apr-util-1.2.2/dbd/apr_dbd_sqlite3.c
--- apr-util-1.2.2-vanilla/dbd/apr_dbd_sqlite3.c 2005-08-11 18:51:16.0
Hopefully, this should be the correct lot of patches (I said that
before, didn't I :-). Once that memory allocation business with SQLite3
column names gets fixed (see previous patches), things are much simpler
and there is really no need for the bogus pool argument.
PS. Apologies for so many
Quoting Bojan Smojver [EMAIL PROTECTED]:
This patch fixes memory allocation problems with column names in both
1.2.2 and trunk. It compiled fine on FC4.
Just being a pest... What are the chances of this patch and the bounds
checking patch for SQLite2/3 being applied to 1.2.x and trunk
Quoting Garrett Rooney [EMAIL PROTECTED]:
On 2/23/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Browsing through the code of DBD, I noticed that SQLite2/3 don't quite
do the advertised bounds checking for get_entry functions. The
following patch should be good for both 1.2.2 and the trunk
Quoting Garrett Rooney [EMAIL PROTECTED]:
Just committed the column names patch to trunk, and will look at the
bounds checking stuff when I get a chance.
Thanks.
BTW, does the column names
stuff need to be fixed in the sqlite2 implementation as well?
It shouldn't need fixing, because
Quoting Garrett Rooney [EMAIL PROTECTED]:
Just committed the column names patch to trunk, and will look at the
bounds checking stuff when I get a chance.
I've forgotten to ask... Any objections to having these two fixes in 1.2.x?
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
Will try to get to it tonight.
Legend! Thanks heaps.
--
Bojan
On Tue, 2006-03-14 at 22:18 -0800, Garrett Rooney wrote:
And it turns out I actually did do it, see r385977 and r385976.
Apologies for wasting your time :-(
--
Bojan
I asked a while back about having a test in this function to this effect:
if (drivers)
return APR_SUCCESS;
This was to make sure that more than one Apache module can call the
function without any ill effect. Obviously, calling this function from
more than one thread would still be unsafe,
Quoting Nick Kew [EMAIL PROTECTED]:
I don't think your suggestion is quite enough, as the lifetime
of drivers is tied to the pool. But if we add a pool cleanup
that resets drivers to NULL, it should be fine AFAICS.
I'll put that in if noone shouts.
Excellent! Thanks.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Hopefully, this should be the correct lot of patches [...snip...]
Just being a pest... Anyone had a chance to take a look?
PS. The e-mail with patches is from 24 Feb 2006, in case you can't
find it (like I couldn't :-). The Oracle patch (not done
Quoting Nick Kew [EMAIL PROTECTED]:
In case you don't follow APR svn commits, I committed patches
including yours to apr_dbd yesterday.
Thanks! Awesome.
--
Bojan
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
When did we drift back to this naming convention?
I thought we were trying to move twords lib_object_subobject_verb?
E.g. apr_dbd_name_get?
It's really aggrivating to use an api that's pulling in both directions
at once :(
Sorry about that. I
Quoting Nick Kew [EMAIL PROTECTED]:
Proposed patch below.
[...snip...]
--- apr_dbd.c (revision 390371)
+++ apr_dbd.c (working copy)
@@ -63,17 +63,32 @@
}
#endif
+static apr_status_t apr_dbd_term(void *ptr)
+{
+/* set drivers to NULL so init can work again */
+drivers =
Quoting Nick Kew [EMAIL PROTECTED]:
Proposed patch below.
One more thing I've forgotten in my previous e-mail. Unless there is
some kind of binary compatibility problem (I don't see it), this would
be a good candidate for backporting to 1.2.x.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
There's no reason for compat macros, this code has not been released
in any version of APR, so compat is not an issue.
I was referring to renaming all DBD functions actually (including the
new ones), so that they follow the naming proper convention
Quoting Garrett Rooney [EMAIL PROTECTED]:
Well, it can be done for 1.3.x, but it would need to be by adding
macros for the NEW names, so the old symbols still exist at link time.
We can't backport such a change to 1.2.x, since it involves adding
new symbols.
I wasn't thinking any of this
Quoting Garrett Rooney [EMAIL PROTECTED]:
1.3.x is compatible with 1.2.x in the sense that programs compiled
against 1.2.x must continue to run against 1.3.x. The reverse is not
true, which is why in minor version number bumps we can add new
functions. To remove functions (or macros for that
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
Right - I wasn't being critical of your specific new fn, but just a general
observation. In the past, we created renames_proposed to collect a list for
review and comment before committing the changes; if you agree with the
syntax _get _set etc,
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Is there are particular reason why PQprepare() isn't used to prepare
statements? Currently, DBD code builds an SQL statement with PREPARE
[...] at the beginning and then executes that, instead of calling the
mentioned API function.
Don't worry about
On Fri, 2006-03-31 at 11:00 +0100, Nick Kew wrote:
--- apr_dbd.c (revision 390371)
+++ apr_dbd.c (working copy)
@@ -63,17 +63,32 @@
}
#endif
+static apr_status_t apr_dbd_term(void *ptr)
+{
+/* set drivers to NULL so init can work again */
+drivers = NULL;
+
+/*
On Fri, 2006-04-07 at 23:49 +0100, Nick Kew wrote:
It's also possible that it did exist
but that the code was written with insufficient reference to TFM.
Do you know when PQprepare first appeared?
If PostgreSQL manuals are accurate (and there is no reason why they
shouldn't be), the first
Quoting Nick Kew [EMAIL PROTECTED]:
[ Please don't Cc: me when you post to the list. One copy
of your messages is enough ]
Ah, sorry :-(
If you want to take that on, feel free. Does it gain us anything?
Not much. Maybe a few CPU cycles that get used for building the string
PREPARE ...
Quoting Bojan Smojver [EMAIL PROTECTED]:
Any chance of a backport of this to 1.2.7?
Just another ping...
--
Bojan
On Sun, 2006-04-09 at 03:14 -0500, William A. Rowe, Jr. wrote:
I'm rolling 5pm UT, and I'm sorry but no cycles and too little understanding
of the dbd API for me to take this on :( Maybe another committer in the
next
9 hours can take a peek?
No worries.
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
Any chance of a backport of this to 1.2.7?
Thanks (r392812 AFAICS)!
--
Bojan
I'm not overly familiar with test specifics in APU, but it would seem
that LIBS doesn't gets set at all, which then causes AC_CHECK_FUNCS to
return false even if the function is actually available. So, the test
is a bit more manual: check for the function inside the library
using
This patch is just a request for comment, to see if I'm on the right
track here. The thing does compile, but I didn't actually test it.
You will note that I have hardcoded OIDs in several places, because if
we want to pick them up from pg_type.h, the detection code in dbd.m4
will have to
On Wed, 2006-04-12 at 15:50 -0700, William A. Rowe, Jr. wrote:
[ ] [ ] [ ] apr-util-1.2.7
There is a bug in apr_dbd_pgsql.c, in function dbd_pgsql_pquery(). Just
before the PQclear() call, there should be:
*nrows = atoi(PQcmdTuples(res));
This applies to both the trunk and 1.2.7.
Without
On Thu, 2006-04-13 at 07:58 -0700, William A. Rowe, Jr. wrote:
Is this a regression?
I don't think so, actually. I think it's always been like this (although
not 100% sure on this).
Thanks for catching this Bojan!
Fixed in trunk, r394013 (my first commit - go easy :-). I believe this
should
On Thu, 2006-04-13 at 05:16 -0400, Craig Rodrigues wrote:
I'm trying to update the FreeBSD port of apr to use this.
Can the following patch go in? Older FreeBSD versions
like to have apr compiled with no thread support.
I didn't actually compile this, but it looks OK to me.
--
Bojan
On Sun, 2006-04-16 at 21:20 +, [EMAIL PROTECTED] wrote:
--- apr/apr-util/branches/1.2.x/dbd/apr_dbd_pgsql.c (original)
+++ apr/apr-util/branches/1.2.x/dbd/apr_dbd_pgsql.c Sun Apr 16 14:19:59 2006
@@ -221,7 +221,7 @@
apr_dbd_t *sql)
{
size_t len
I tested this patch with 1.2.x, but I'd like people to check if all is
cool before it gets committed to any branch/trunk. Essentially, we're
not assuming any more that the sqlite3_step() call is always going to be
successful - this call can return SQLITE_BUSY just the same as the one
inside the
On Mon, 2006-04-17 at 16:11 +1000, Bojan Smojver wrote:
I tested this patch with 1.2.x,
Yeah, and I also applied it to trunk as if it were for 1.2.x - sorry.
The mutex calls should be different. Here is a better version.
--
Bojan
Index: apr_dbd_sqlite3.c
In fact, this can be done even simpler. Reworked patch attached.
--
Bojan
Index: apr_dbd_sqlite3.c
===
--- apr_dbd_sqlite3.c (revision 394781)
+++ apr_dbd_sqlite3.c (working copy)
@@ -253,11 +253,24 @@
apr_dbd_mutex_lock();
Quoting [EMAIL PROTECTED]:
Retry SQLite3 query on BUSY
This is in trunk now, but if nobody objects, I would like to backport
it to 1.2.x as well.
--
Bojan
These two patches enable prepared statements in SQLite3, for both the
trunk and 1.2.x. Surprisingly :-), I actually did test this code to
some extent, so the basics should be OK. However, please hammer it and
let me know.
--
Bojan
Index: dbd/apr_dbd_sqlite3.c
Quoting Bojan Smojver [EMAIL PROTECTED]:
These two patches
In the patch for the trunk, every apr_dbd_mutex_[un]lock(sql-mutex)
should not have sql-mutex argument, of course. Sorry about that -
I'll blame this one on early morning/lack of caffeine ;-)
--
Bojan
On Mon, 2006-04-24 at 16:13 -0400, Tom Bradford wrote:
Sorry, but Doxygen and a slideshow with little to no actual
information (both of which I've already seen) do not a suite of
documentation make.Doxygen is as valuable in the grand scheme of
things as is Javadoc, and that's not much
On Mon, 2006-04-24 at 17:07 -0400, Tom Bradford wrote:
By DBM-style, I mean you're effectively talking about the storage of
key/value pairs where the atom representation of a value is
effectively a void pointer, rather than tuples, which is how SQLite
and other RDBMS' inherently
On Tue, 2006-04-25 at 07:58 -0700, Garrett Rooney wrote:
Bojan, if you're merging a revision from trunk to a branch (or
vice-versa for that matter) please mention that in the commit log, so
people know that's what's happening. If you don't mention that it's a
merge, my immediate response to
On Tue, 2006-04-25 at 07:58 -0700, Garrett Rooney wrote:
if you're merging a revision from trunk to a branch (or
vice-versa for that matter)
Just occurred to me - if there is a backport from the trunk to a branch
that isn't a straight merge (i.e. the patch needs adjusting in order to
work), do
Quoting Garrett Rooney [EMAIL PROTECTED]:
On 4/27/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Is there something I missed here or does that look like a real bug in
SQLite DBD driver?
Sounds problematic to me. Perhaps one of the users of the sqlite
drivers (we have a few on this list, IIRC
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
I do not have a fix for this (or else I would have sent a patch) since
I decided to use apr_dbd_query() directly to begin and commit/rollback
a transaction, this was necessary apr_dbd api did not have a rollback
function, which is an issue I mentioned as
Here is a quick patch that should get rid of the commit twice code.
I also removed explicit rollback, as it is not required (SQLite3 rolls
back by itself when things aren't good).
Note also that the default return code was changed to -1 in this
patch. It is normally an error to end a
This was never compiled, let alone tested. It is here as a prototype
for Ronen's suggestion.
--
Bojan
Index: include/apr_dbd.h
===
--- include/apr_dbd.h (revision 397754)
+++ include/apr_dbd.h (working copy)
@@ -153,6 +153,18 @@
Quoting Bojan Smojver [EMAIL PROTECTED]:
Here is a quick patch that should get rid of the commit twice code.
A variant with a more conservative approach.
This one also returns success if rollback was successful. I'm not sure
what semantics is supposed to be here, but other drivers appear
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
Quoting Ronen Mizrahi [EMAIL PROTECTED]:
Looks good to me
I think we should go with the second version of the patch, in order to
keep in line with other drivers that return 0 if rollback was a
success. Does that work for you?
--
Bojan
Quoting Bojan Smojver [EMAIL PROTECTED]:
I'll test this and wait for the feedback before I commit.
This patch would not in fact work at all. Function dbd_sqlite_query()
checks the error code of the transaction before it does anything and
bails of the status is bad. Therefore, bad
Quoting ISF - Hassan Shabbir [EMAIL PROTECTED]:
gcc -o test test.o $(LIB)
Have you tried with -lapr-0 -laprutil-0 (or similar) at the end of
the above?
--
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 this would
On Fri, 2006-04-28 at 10:41 +0100, Nick Kew wrote:
Which reminds me: what's the function of the numeric suffix?
Probably to be able to have multiple binary incompatible major versions
installed in parallel.
--
Bojan
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
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
I reworked the prepared statement support for SQLite3 a little bit (the
linking of statements to the handle didn't really work in the original
patches and there was some unnecessary memory allocation as well). If
nobody objects, I would like to commit this to the trunk in the next few
days.
Not
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
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.
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
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
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) {
^
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
1 - 100 of 930 matches
Mail list logo
