Database environments are convenient for configuring a group of Berkeley
databases that will be used together. Using database environments
together with the Concurrent Data Store mode with multiple database files
allows you to have multiple applications all reading and writing to the
database files, and Berkeley DB takes care of locking to make sure that
the files don't become corrupt.

The default database environment in STLdb4 is effectively a
null environment. New database environments are created using the
Environment class. The static Environment::setDefault() method can be
used in applications using a single database environment to avoid having
to pass the database environment object to the Database constructor.

The code shown in Listing 11 uses a database environment to
protect two database files from simultaneous update by multiple running
processes. First, a new database environment is created and set to use
the Concurrent Data Store mode. This database environment is set to be
the default STLdb4 environment. The first Database object is created
using the default database environment; the second Database object is
created by specifying the database environment explicitly and opening
the database file as a separate call.

The ordering of elements in the database can be changed with
Database::set_bt_compare() using either a function pointer or a Loki
functor object. For details on Loki functors, refer to the Modern C++
Design book (see the on-line Resources). As the comparison function is a relatively low-level
operation, no implicit conversions happen for this, and you must compare
two Dbt values. A collection of functions for numeric comparison,
such as getInt32Compare() and string comparison with and without case
sensitivity using getCISCompare(), are available in STLdb4. The ordering of
a comparison functor can be reversed by passing it to makeReverseCompare()
to create a new functor. These operations must be performed before the
database is open, so you have to use the open() or create() calls and the
non-opening Database constructor as shown in Listing 12.

A template subclass of Database taking parameters similar to std::map<>
would be nice. There would need to be some extra work to allow both the
key and value to be (de)serialized on demand perhaps by assuming that
both can be Boost serialized.

Ben Martin has been working on filesystems for more than ten years. He is
currently working toward a PhD at the University of Wollongong,
Australia, combining Semantic Filesystems with Formal Concept Analysis
to improve human-filesystem interaction.

After reading this article, I have been using STLdb4, and am very pleased with it! It could use a few touchups, but since you can
always get the raw BerkeleyDB pointer there's nothing I haven't been
able to accomplish yet. *SO* much nicer to work with than the existing C++ implementation. Good job!