Hi all,
BerkleyDB is gone in SUSE and going away in RHEL[1]. How does this practically
affect the apr-dbd API?
We support gdbm, but that’s GPLv3. Do we need a new implementation?
[1] https://access.redhat.com/articles/6464541
Regards,
Graham
—
Hi folks,
Is apr_dbd support 'batching' or 'array binding' ? Or anyone working on it ?
Regards,
Dongsheng Song
On Sun, 2007-13-05 at 18:31 +1000, Ian Holsman wrote:
Hi Guys,
One of the 'new' features of mysql (in 5.0) is the support of multiple
result sets being returned to the client, and the ability to send
multiple statements in 1 shot by setting a flag when you open the
connection. Multiple
On 14 May 2007, at 23:49, Matthew Kent wrote:
On Sun, 2007-13-05 at 18:31 +1000, Ian Holsman wrote:
Hi Guys,
One of the 'new' features of mysql (in 5.0) is the support of
multiple
result sets being returned to the client, and the ability to send
multiple statements in 1 shot by setting a
On Tue, 2007-05-15 at 00:23 +0100, Nick Kew wrote:
Anyone care to draft
and propose an API extension for it?
I guess the simplest thing to do would be to keep the API as is.
For _[pb]query functions, nrows passed in can be a pointer to an array,
which has the size of the number of queries,
Nick Kew wrote:
On 14 May 2007, at 23:49, Matthew Kent wrote:
On Sun, 2007-13-05 at 18:31 +1000, Ian Holsman wrote:
Hi Guys,
One of the 'new' features of mysql (in 5.0) is the support of multiple
result sets being returned to the client, and the ability to send
multiple statements in 1 shot
On Sun, 2007-05-13 at 18:31 +1000, Ian Holsman wrote:
Is this functionality interesting for the APR DBD library in general,
Is there similar functionality available in other db's that people know of?
SQLite does it as well. And strangely enough, we actually support some
queries like that (but
On Friday 23 June 2006 04:36, Evgeny Shirykalov wrote:
Dear All,
Current version of Postgres driver for apr_dbd returns ExecStatusType
values from query-like functions. This behaviour leads to two
unconvenient consequences:
Yes, this has been discussed recently on the [EMAIL PROTECTED] list
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
yours to apr_dbd yesterday.
Thank you.
--
Nick Kew
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 by
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
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
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
On Wednesday 22 February 2006 07:26, you wrote:
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
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
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
On Wednesday 22 February 2006 02:03, Bojan Smojver wrote:
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
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
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.
Bill
Bojan Smojver wrote:
On Mon, 2006-02-13 at 19:54 +, Nick Kew wrote:
It'll have to wait for 1.3, 'cos it affects the API
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
On Monday 13 February 2006 07:16, Bojan Smojver wrote:
Is there a way to get result set column names with apr_dbd? I couldn't
find one...
There isn't. But you're not the first to ask for this feature,
so I guess it's a strong candidate for inclusion in a future update.
If the feature really
On Mon, Feb 13, 2006 at 10:52:24AM +, Nick Kew wrote:
On Monday 13 February 2006 07:16, Bojan Smojver wrote:
Is there a way to get result set column names with apr_dbd? I couldn't
find one...
There isn't. But you're not the first to ask for this feature,
so I guess it's a strong
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
Bojan Smojver wrote:
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.
Here's a patch for the apr_dbd_oracle driver that has the
On Monday 13 February 2006 19:10, Bojan Smojver wrote:
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.
It'll have to wait for 1.3,
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
anything is to retain the
existing get_entry as-is, and introduce an apr_dbd_get_typed_entry
defined as above. That would of course be an extra entry on the
end of the apr_dbd_driver_t struct.
A possible followup to this would be a function to set properties
of apr_dbd objects. This can be introduced
Garrett Rooney wrote:
The simple fix to (2) without breaking anything is to retain the
existing get_entry as-is, and introduce an apr_dbd_get_typed_entry
defined as above. That would of course be an extra entry on the
end of the apr_dbd_driver_t struct.
Can we really do that? Adding an
--On August 9, 2005 11:27:23 AM -0700 Garrett Rooney
[EMAIL PROTECTED] wrote:
Can we really do that? Adding an entry to the end of the apr_dbd_driver_t
struct will change its size, and it's defined in a public header file, so I
think that might be against our versioning guidelines, strictly
Justin Erenkrantz wrote:
--On August 9, 2005 11:27:23 AM -0700 Garrett Rooney
[EMAIL PROTECTED] wrote:
Can we really do that? Adding an entry to the end of the
apr_dbd_driver_t
struct will change its size, and it's defined in a public header file,
so I
think that might be against our
Nick Kew wrote:
Garrett Rooney wrote:
The simple fix to (2) without breaking anything is to retain the
existing get_entry as-is, and introduce an apr_dbd_get_typed_entry
defined as above. That would of course be an extra entry on the
end of the apr_dbd_driver_t struct.
Can we really do
On Tuesday 09 August 2005 20:14, Garrett Rooney wrote:
If you're adding a member to a struct that's defined in a public header
file, how is that maintaining binary compatibility? The size of the
structure has changed, so anyone depending on that size is now broken.
This is a struct that's
Nick Kew wrote:
On Tuesday 09 August 2005 20:14, Garrett Rooney wrote:
If you're adding a member to a struct that's defined in a public header
file, how is that maintaining binary compatibility? The size of the
structure has changed, so anyone depending on that size is now broken.
This is
Nick Kew wrote:
Anyway, as I said, a placeholder now fixes that.
Out of curiosity, is there any reason we can't just forward declare the
struct and access the internals via some accessor functions? I mean
it's a database library, so it's going to be doing a lot of I/O, I can't
imagine the
that might be against our versioning guidelines, strictly
speaking...
apr-dbd hasn't been in a release yet. So, it doesn't matter. -- justin
Yeah, but Nick is talking about making the change after we release
what we've got now, so there would have been a release at that point.
If the apr_dbd
definite stumbling block there: the varargs APIs.
Can the vararg functions (specifically, the pvquery and pvselect
functions) be expressed as apr_dbd #defines, like the rest of
the calls? Anyone?
I mean
it's a database library, so it's going to be doing a lot of I/O, I can't
imagine the overhead
.
There's one definite stumbling block there: the varargs APIs.
Can the vararg functions (specifically, the pvquery and pvselect
functions) be expressed as apr_dbd #defines, like the rest of
the calls? Anyone?
Why does that matter? My suggestion doesn't involve any wrapper
defines, just
On 8/4/05, Nick Kew [EMAIL PROTECTED] wrote:
Hi Nick,
As indicated in my post of a few weeks ago, I'd like to support typed
data in apr_dbd. I posted a patch that would change (and break) the
API. Since apr_dbd hasn't yet featured in a release version, there was
no absolute reason
John Vandenberg wrote:
On 8/4/05, Nick Kew [EMAIL PROTECTED] wrote:
Hi Nick,
As indicated in my post of a few weeks ago, I'd like to support typed
data in apr_dbd. I posted a patch that would change (and break) the
API. Since apr_dbd hasn't yet featured in a release version
John Vandenberg wrote:
On 8/4/05, Nick Kew [EMAIL PROTECTED] wrote:
Hi Nick,
As indicated in my post of a few weeks ago, I'd like to support typed
data in apr_dbd. I posted a patch that would change (and break) the
API. Since apr_dbd hasn't yet featured in a release version
will apr_dbd be part of a release?Rick KeinerNick Kew [EMAIL PROTECTED] wrote:
The current apr_dbd implementation represents all data as strings(const char*). This is fine with pgsql, mysql and sqlite.I'm attempting to hack up apr_dbd for oracle, and it appears altogetherless happy
The current apr_dbd implementation represents all data as strings
(const char*). This is fine with pgsql, mysql and sqlite.
I'm attempting to hack up apr_dbd for oracle, and it appears altogether
less happy with this approach. So I'm contemplating replacing const char*
with an apr_dbd_datum_t
Nick Kew wrote:
I'll try and find time to make the proposed change between now and the
end of the week.
There's a little more complexity than I realised, due to transactions
being tied to pools (looks like a bug in the current pgsql, too).
And I've had less time than expected. So I'm going to
a limit to what we want apr_dbd to do, and application
developers can add to it where necessary. Having any transactions at
all in apr_dbd is just a minor convenience.
--
Nick Kew
Nick Kew wrote:
Paul Querna wrote:
Garrett Rooney wrote:
Nick Kew wrote:
However, we have what now appears to be a redundant argument:
I think the reason I left it in the prototype was on the off chance that
we want to be able to handle recursive transactions of some sort. Of
course, I have
try and find time to make the proposed change between now and the
end of the week.
One of these days, we'll get around to rolling an apr-util release
incorporating apr_dbd. And I'm going to try and grab someone from
MySQL re: the licensing issue at ApacheCon if nothing has happened
Nick Kew wrote:
I'll try and find time to make the proposed change between now and the
end of the week.
Excellent.
One of these days, we'll get around to rolling an apr-util release
incorporating apr_dbd.
Personally, I'd prefer that we update the autoconf glue to build
separate libraries
The original apr_dbd implementation had transactions being
passed to all relevant functions as apr_dbd_transaction_t*
argument.
This was changed to make the current transaction a field
of an apr_dbd_t, and remove the argument from functions.
However, we have what now appears to be a redundant
Nick Kew wrote:
The original apr_dbd implementation had transactions being
passed to all relevant functions as apr_dbd_transaction_t*
argument.
This was changed to make the current transaction a field
of an apr_dbd_t, and remove the argument from functions.
However, we have what now appears
Garrett Rooney wrote:
Nick Kew wrote:
The original apr_dbd implementation had transactions being
passed to all relevant functions as apr_dbd_transaction_t*
argument.
This was changed to make the current transaction a field
of an apr_dbd_t, and remove the argument from functions.
However
--- Nick Kew [EMAIL PROTECTED] wrote:
Rick Keiner wrote:
Here is some work I've done on the SQLite driver
for
apr_dbd. It's based on the work Ryan Phillips had
done.
Thanks for reminding me: I've been meaning to look
at Ryan's patch,
but round tuits have been very difficult (illness
Here is some work I've done on the SQLite driver for
apr_dbd. It's based on the work Ryan Phillips had
done. I've changed the select to build a linked list
of the result set so that the number of tuples will be
correct. The subsequent get rows retrieve the data
from the linked list. This works
Rick Keiner wrote:
Here is some work I've done on the SQLite driver for
apr_dbd. It's based on the work Ryan Phillips had
done. I've changed the select to build a linked list
of the result set so that the number of tuples will be
correct. The subsequent get rows retrieve the data
from the linked
Rick Keiner wrote:
Here is some work I've done on the SQLite driver for
apr_dbd. It's based on the work Ryan Phillips had
done.
Thanks for reminding me: I've been meaning to look at Ryan's patch,
but round tuits have been very difficult (illness followed by house
move).
I notice
On Tue, 22 Feb 2005 10:56:24 +, Nick Kew wrote:
One more point here: for DSO loading of drivers, we could perhaps use
a magic versioning number. Making that APR-wide would make sense,
preparing the ground for possible APR module support in other areas.
Any thoughts?
Well, my hacking
I'm finally starting to hack away at Nick's new DBD API for APR, and have
noticed a few things about the API, which I have talked with Nick about on
IRC. And would like the thoughts of others.
One is a capabilities function in the driver API, to provide a way for the
application to figure out
Edward Rudd wrote:
I'm finally starting to hack away at Nick's new DBD API for APR, and have
noticed a few things about the API, which I have talked with Nick about on
IRC. And would like the thoughts of others.
One is a capabilities function in the driver API, to provide a way for the
application
On Mon, Feb 21, 2005 at 09:17:03PM -0500, Garrett Rooney wrote:
I agree, it would be good to do something about that. You might want to
look at how the ldap API handles this kind of thing. If I recall
correctly they've got some sort of error object they return which in our
case could
Edward Rudd wrote:
I'm finally starting to hack away at Nick's new DBD API for APR, and have
noticed a few things about the API, which I have talked with Nick about on
IRC. And would like the thoughts of others.
One is a capabilities function in the driver API, to provide a way for the
Nick Kew said:
The other thing I noticed was the lack of standardized return codes from
the functions.
Again, agreed. I'm not quite sure what the procedure is for introducing
new APR error codes, but ideally we should do that.
I ran into the same problem with this in APR-util and the LDAP
Hi!
Ryan alerted me to this thread. I run engineering at MySQL and spend
some of my time working on community issues.
So I have read the thread so far concerning MySQL and the apr and have
a few questions, so please bare with me while I try to understand the
problem.
So, you have a
On Feb 7, 2005, at 2:46 PM, Brian Aker wrote:
The GPL boils down for us to a simple Quid Pro Quo. If you are open
source, we are open source. This means that if you write an open
source application then you should have zero to worry about, if you
are writing a closed source application and need
Hi!
On Feb 7, 2005, at 12:07 PM, Jim Jagielski wrote:
PHP has. APR itself is basically a library, used by HTTPD as well
as others. apr-dbd is very useful, but the most popular usage of
it would be within its MySQL support (think of it as an apr equiv
On a different note, who coded this? I can have
coded this? I can have one of our connector
writers go over it and see if we can do any improvement on the layer. I
would be happy to dedicate some engineering resources to improve on this
if need be.
The original author of apr_dbd is Nick Kew, and the MySQL specific code
is still available from
Right, I don't believe you need a FLOSS exception. The ASF's license
is compatible with MySQL's thoughts on what the GPL is compatible
with. Namely the interface can exist and there are no issues with it
being made available. Its the last mile that is at question. If
someone compiles the apr
can use MySQL via APR with apr_dbd.
The question is over how the MySQL driver in apr_dbd is licensed
and distributed. The options are to keep it separate and under the GPL,
or to bundle it with APR under the ASF license. Speaking as the original
author, I had in mind the former, but am happy
, using the base class. apr_dbd is distilled from
that, dumping C++ and project-specific functionality and expanding the
generic/reusable stuff after discussion on this list.
So I guess that's what apr_dbd is:-)
its API. Another way of looking at it would be if we had an
auth module
Nick Kew wrote:
On Saturday 05 February 2005 21:15, David Reid wrote:
They do seem, as an organisation, to be quite well aware that
restricting their reach by licensing isn't helpful and therefore seem
qilling to talk about exceptions and different clauses, so maybe such a
clause can
Jim Jagielski wrote:
Nick Kew wrote:
On Saturday 05 February 2005 21:15, David Reid wrote:
They do seem, as an organisation, to be quite well aware that
restricting their reach by licensing isn't helpful and therefore seem
qilling to talk about exceptions and different clauses, so maybe such a
Mail sent to Brian Aker at MySQL. If he responds directly to me, I
will let the list know.
Ryan
On Sun, 06 Feb 2005 07:30:04 +, David Reid [EMAIL PROTECTED] wrote:
Jim Jagielski wrote:
Nick Kew wrote:
On Saturday 05 February 2005 21:15, David Reid wrote:
They do seem, as an
of the APR - i.e. does it give them an exception to the GPL too?
My proposal is to retain and properly document what we have right now,
and provide facilities at the configure/build level to make it easy for users:
* The apr_dbd base, the existing pgsql driver, and other drivers as and when
I was planning to copy this to [EMAIL PROTECTED], but their website just has a
contact form rather than any useful address, so I'm going to have to point
them to this post instead:-(
I'd have thought this was a sensible plan and hopefully someone here
know someone?
david
On Sat, Feb 05, 2005 at 11:07:20AM +, Nick Kew wrote:
I don't know if MySQL's exception for open source projects would cover us.
I'm not really happy with it: it looks to me like a potential torpedo under
the whole of MySQL's GPL licensing. It also raises ugly questions over
whether it
Justin Erenkrantz wrote:
On Sat, Feb 05, 2005 at 11:07:20AM +, Nick Kew wrote:
I don't know if MySQL's exception for open source projects would cover us.
I'm not really happy with it: it looks to me like a potential torpedo under
the whole of MySQL's GPL licensing. It also raises ugly
On Thursday 03 February 2005 00:46, Garrett Rooney wrote:
I'm wondering if the way transactions fit into the current API makes
sense... Currently we've got a transaction argument that gets passed
into each function that calls into the database. In the postgres impl
all it seems to do is
Nick Kew wrote:
On Thursday 03 February 2005 00:46, Garrett Rooney wrote:
I'm wondering if the way transactions fit into the current API makes
sense... Currently we've got a transaction argument that gets passed
into each function that calls into the database. In the postgres impl
all it seems
On Friday 04 February 2005 15:49, Garrett Rooney wrote:
If you don't have any objection I'll look at pulling it out of the API
and into the dbd object this weekend.
Fine with me. It's not going to hit the top of my own to-do list in
that time, anyway:-)
--
Nick Kew
I'm wondering if the way transactions fit into the current API makes
sense... Currently we've got a transaction argument that gets passed
into each function that calls into the database. In the postgres impl
all it seems to do is store an error value, which is used to bail out in
the case
On Wed, Feb 02, 2005 at 05:45:30AM +, Nick Kew wrote:
I've just committed the first apr_dbd code to apr-util:
- adding headers without building the code breaks the httpd build
- test code should go in test/ not dbd/
- is the reslist comment at the top of apr_dbd.h still relevant
On Thursday 03 February 2005 12:30, Joe Orton wrote:
On Wed, Feb 02, 2005 at 05:45:30AM +, Nick Kew wrote:
I've just committed the first apr_dbd code to apr-util:
- adding headers without building the code breaks the httpd build
Oops, sorry!
- test code should go in test/ not dbd
I've just committed the first apr_dbd code to apr-util:
Included:
include/apr_dbd.h
dbd/apr_dbd.c
dbd/apr_dbd_pgsql.c
dbd/apr_dbd_test.c
Not included:
dbd/apr_dbd_mysql.c
I need to clarify the licensing issue with MySQL and GPL. I think MySQL's
opensource special clause should technically
My website has said since mid-December that apr_dbd will be released
under opensource license terms in January.
It's now Jan.30th, and this is getting embarrassing. I therefore intend to
fix this tomorrow, regardless. In the absence of APR karma, my proposal
to contribute the code to ASF
On Sun, 30 Jan 2005, Nick Kew wrote:
If anyone with APR karma would like to take responsibility for committing
it, please contact me within 24 hours to discuss logistics.
This was me dropping the ball, and the problem is being corrected...
Nick Kew wrote:
My website has said since mid-December that apr_dbd will be released
under opensource license terms in January.
It's now Jan.30th, and this is getting embarrassing. I therefore intend to
fix this tomorrow, regardless. In the absence of APR karma, my proposal
to contribute
On Jan 30, 2005, at 12:47 PM, Nick Kew wrote:
My website has said since mid-December that apr_dbd will be released
under opensource license terms in January.
It's now Jan.30th, and this is getting embarrassing. I therefore
intend to
fix this tomorrow, regardless. In the absence of APR karma, my
Ersin Er wrote:
I wish we'll see a user's guide for the library. I seems pretty useful.
Was that about apr_dbd, or about APR in general?
One reason for integrating it into APR is that it then gets the
benefit of doxygen-generated documentation of the API.
As regards tutorials, I have a few
Nick Kew wrote:
Ersin Er wrote:
I wish we'll see a user's guide for the library. I seems pretty useful.
Was that about apr_dbd, or about APR in general?
About APR in general and about apr_dbd in particular. I mentioned
apr_dbd in fact but I want to mention the lack of documentation for APR
here
I've made some more updates, mainly improvements to the API and
factoring out of differences between SQL syntaxes to improve
portability of applications (most importantly, my own:-)
I've also found and fixed the bug that was affecting the prepared
query test in the PostgreSQL driver.
I won't
Nick Kew wrote:
/* These are opaque structs. Instantiation is up to each backend */
#ifndef APR_DBD_INTERNAL
typedef struct apr_dbd_t apr_dbd_t;
typedef struct apr_dbd_transaction apr_dbd_transaction;
typedef struct apr_dbd_results apr_dbd_results;
typedef struct apr_dbd_row apr_dbd_row;
typedef
On Thu, 9 Dec 2004, Garrett Rooney wrote:
But it's temporary allocation. You create a temp subpool at the
beginning of the function, use it for the parsing and whatnot, then kill
the pool at the end.
Isn't that significant extra overhead compared to just passing in
an existing process-pool
On Fri, 10 Dec 2004, Branko ^Libej wrote:
Nick Kew wrote:
/* These are opaque structs. Instantiation is up to each backend */
#ifndef APR_DBD_INTERNAL
typedef struct apr_dbd_t apr_dbd_t;
typedef struct apr_dbd_transaction apr_dbd_transaction;
typedef struct apr_dbd_results
Nick Kew wrote:
On Fri, 10 Dec 2004, Branko ^Libej wrote:
Nick Kew wrote:
/* These are opaque structs. Instantiation is up to each backend */
#ifndef APR_DBD_INTERNAL
typedef struct apr_dbd_t apr_dbd_t;
typedef struct apr_dbd_transaction apr_dbd_transaction;
typedef struct apr_dbd_results
On Fri, 10 Dec 2004, Branko ^Libej wrote:
The #ifndef is because *drivers* have to declare them before
#including apr_dbd.h.
They don't have to declare them before including the header. This
sequence is completely valid:
typedef struct foo foo;
struct foo {
int bar;
Nick Kew wrote:
To take a real example from the existing drivers, that works with
typedef struct apr_dbd_prepared apr_dbd_prepared;
struct apr_dbd_prepared {
const char *name;
int prepared;
};
but fails with
typedef struct apr_dbd_prepared apr_dbd_prepared;
typedef
Nick Kew wrote:
On Thu, 9 Dec 2004, Garrett Rooney wrote:
But it's temporary allocation. You create a temp subpool at the
beginning of the function, use it for the parsing and whatnot, then kill
the pool at the end.
Isn't that significant extra overhead compared to just passing in
an existing
On Mon, 6 Dec 2004, Nick Kew wrote:
Currently I have code for a proposed apr_dbd that compiles and loads
cleanly, comprising apr_dbd.[c|h], a MySQL driver apr_dbd_mysql,
I've now added a test program, and the drivers for MySQL and PostgreSQL
work for me. Time to post here for preliminary
1 - 100 of 114 matches
Mail list logo
