+1 SDBM as currently implemented is next to useless on a large number of records either.As a few here already know, we used the 'Standard' page size for our apr-util SDBM implementation. This assures that you can modify our sdbm files from perl and other tools.
However, it's pretty clear that 1024 just doesn't cut it when it comes to huge objects from ssl caching and other sorts of large blobs. The modssl project (1.3) had tweaked sdbm to take larger page sizes, but this leads to an inflexible implementation (another fixed page size, but incompatible with other implementations.)
I'd like to see apr-util support alternate sized dbm pages, but without
making fixed assumptions about those sizes (other than this - the structure uses short's for offsets, so the page size does have a cap.)
The attached patch allows the SDBM to be of any arbitrary data and directory page sizes. However, I've not hacked in any method of declaring what those sizes should be (they are the 'standard' defaults at the moment.)
What do folks believe is the most rational approach to expanding support to create an sdbm with alternate page sizes? And how best can we embed that info into the sdbm so that later accesses to the file use the correct
page size? My current thought is to embed a NULL-key record at the head
of the file, with a specific known value element containing some identifier
string such as "APR-SDBM" followed by two ints, the page and data len.
If that record is missing (or created with default sizes), the file is treated as a standard sdbm with 1024/4096 sized pages.
Other thoughts, suggestions or observations?
Bill
you'll need to modify apr_dbm_open call so it can pass a page size (so you can create the sucker)
I'm still curious on why people just don't use berkeley DB (except for licencing issues I guess)
are there any other BSD-style DBM formats we could use?
