apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: [proposal] DBM - allow multiple DBM's of differnt types at the same time.
Date Mon, 20 Aug 2001 19:08:37 GMT
Ryan Bloom wrote:

>On Monday 20 August 2001 11:46, Cliff Woolley wrote:
>>On Mon, 20 Aug 2001, Sterling Hughes wrote:
>>>>yes.. thats the point of the patch
>>>>#include <apr_dbm_sdbm.h>
>>>>#include <apr_dbm_db.h>
>>>>apr_dbm_t  b1= apr_dbm_open_sdbm(...);
>>>>apr_dbm_t b2= apr_dbm_open_db(...);
>>>>should work.
>>>>the 'test' program will have a update later which will allow it to
>>>>choose DB types (-t DB|SDBM|GDBM)
>>>	Ahh, ok...  I was thinking something more inline with:
>>>	#include <apr_dbm.h>
>>>	apr_dmb_t b1 = apr_dbm_open(APR_GDBM, ...);
>>>	But either way works.
>>Different parts of APR and apr-util use one method or the other, so it's
>>hard to say which is more consistent.  Some use Ian's method (eg buckets,
>>sms), some use yours (eg locks).  I think I like Ian's flavor (the
>>apr_dbm_open_foo one) better in this context because it's probably more
>>easily extensible by an outside module that might know about some flavor
>>of dbm we don't know about.  But that's just me.  <shrug>
>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

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

>Ryan Bloom                        	rbb@apache.org
>Covalent Technologies			rbb@covalent.net

View raw message