apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@webperf.org>
Subject Re: [proposal] DBM - allow multiple DBM's of differnt types at the same time.
Date Mon, 20 Aug 2001 23:50:25 GMT
On Mon, 2001-08-20 at 13:07, Sterling Hughes wrote:
> > >
> > >Well, I think we should choose one, and just follow that one model.  I personally
> > >would rather use an argument to specify the type.  We can't do that with buckets,
> > >because that would require function overloading.  SMS should move to just
> > >a simple argument IMHO though.
> > >
> > the problem passing a option to the dbm open is twofold.
> >
> > 1. If I want to add another dbm  (say NuSQL's genesis or some comerical
> > package) I would then need to
> > modify apr-util and add the flag. this means a branch and will present a
> > road block for me upgrading apr-util
> >
> 	Not sure I understand what you're saying?  There are ways to allow
> 	the registering of module functionality, without modifying the main
> 	package.  Just provide a function like:
> 	apr_dbm_register()
> 	Which registers a dbm internally, and then have a constant defined
> 	in a seperate file, and all is clear...
that would work,
but that wouldn't that mean there would be need to some init code
somewhere to call the registration function?
> > 2. I may have a dbm which needs extra parameters to open it. (say for
> > exampe cache size, or maybe it requires
> >     a fixed key length defined) I couldn't do this simply
> >
> 	dbm_set_x() and check the flags, once they're all filled out (a
> 	va_args implementation could also be done...)
> 	Furthermore, the idea of an abstraction layer is too bring all these
> 	down to a lowest common denominator, at the cost of functionality
> 	sometimes; usually functions that take extra arguments, can be
> 	filled in with acceptable defaults.  You'll run into the same
> 	problems in that some db's don't support certain features, and
> 	others do, the idea is to concentrate on the functionality that is
> 	necessary and shared between the different db's (wrap this in a
> 	large imho :).

true, thats why they all return the same thing (apr_dbm_t)
the open_DBM function was supposed to be called when the devloper wanted
to do something specific with this type of dbm. so in the berkley DB
case there could be a apr_dbm_db_getRaw() function which returns the DB*
so that developers are not constrained the set of functions we chose to

(BTW I was planning on implmenting a shared-memory hash table, that I
posted ages ago, via this DBM interface, and it required a different set
of opening parameters (key/elem size, #elements) these parameters could
be passed via a db_set function call but it would look clunky


shall we put it to a vote?


(I'm assuming that APR-Committers are happy that I go messing with dbm
in the first place ;-)
> 	-Sterling

View raw message