Changes

For example, there is esmith::DB::db to interface with esmith::db flatfile databases. There could also be esmith::DB::Berkeley to use Berkeley database files, or even esmith::DB::DBI.

For example, there is esmith::DB::db to interface with esmith::db flatfile databases. There could also be esmith::DB::Berkeley to use Berkeley database files, or even esmith::DB::DBI.

Most of the methods herein are ``virtual''. They don't exist. The subclass is responsible for impelmenting them. There are a handful of concrete methods that have been implemented for you that should work with any subclass.

Most of the methods herein are ''virtual''. They don't exist. The subclass is responsible for impelmenting them. There are a handful of concrete methods that have been implemented for you that should work with any subclass.

====Virtual Methods====

====Virtual Methods====

The defaults are loaded from /etc/e-smith/db/<dbname>/migrate by default, but the environment variable ESMITH_DB_DEFAULTSDIR can be set to use a different hierarchy if required.

The defaults are loaded from /etc/e-smith/db/<dbname>/migrate by default, but the environment variable ESMITH_DB_DEFAULTSDIR can be set to use a different hierarchy if required.

The entries in ``migrate'' are perl fragments which will be evaluated and so can munge anything they choose to. But, please be gentle :-)

The entries in ''migrate'' are perl fragments which will be evaluated and so can munge anything they choose to. But, please be gentle :-)

So you could have

So you could have

Each of these directories is arranged as a set of subdirectories, with the directory name equal to the key for the given database. With these subdirectories are files, which are named by the properties of these database keys.

Each of these directories is arranged as a set of subdirectories, with the directory name equal to the key for the given database. With these subdirectories are files, which are named by the properties of these database keys.

The entries in ``defaults'' will be skipped if the existing key/property already exists (unless the $forceReset argument is provided). These are simple files, whose contents are the value to be used for that property.

The entries in ''defaults'' will be skipped if the existing key/property already exists (unless the $forceReset argument is provided). These are simple files, whose contents are the value to be used for that property.

The entries in ``force'' are always loaded into the given key/property. These are again simple files, like ``defaults''.

The entries in ''force'' are always loaded into the given key/property. These are again simple files, like ''defaults''.

To make this concrete, you might have:

To make this concrete, you might have:

     /etc/e-smith/db/configuration/defaults/sshd/access

     /etc/e-smith/db/configuration/defaults/sshd/access

containing the single word ``private'', which would be the default. This value would only be used if no ``access'' property existed, or the $forceReset option is passed.

containing the single word ''private'', which would be the default. This value would only be used if no ''access'' property existed, or the $forceReset option is passed.

You can override both ``defaults'' and ``migrate'' with

You can override both ''defaults'' and ''migrate'' with

     /etc/e-smith/db/configuration/force/sshd/access

     /etc/e-smith/db/configuration/force/sshd/access

containing the single word ``public'' to force the value of that property.

containing the single word ''public'' to force the value of that property.

==== get_value_and_delete ($key) ====

==== get_value_and_delete ($key) ====