view release on metacpan or  search on metacpan

BerkeleyDB.pod.P  view on Meta::CPAN

installed.

To summarise:

=over 5

=item B<filter_store_key>

If a filter has been installed with this method, it will be invoked
every time you write a key to a DBM database.

=item B<filter_store_value>

If a filter has been installed with this method, it will be invoked
every time you write a value to a DBM database.


=item B<filter_fetch_key>

If a filter has been installed with this method, it will be invoked
every time you read a key from a DBM database.

=item B<filter_fetch_value>

If a filter has been installed with this method, it will be invoked
every time you read a value from a DBM database.

=back

You can use any combination of the methods, from none, to all four.

All filter methods return the existing filter, if present, or C<undef>
in not.

To delete a filter pass C<undef> to it.

=head2 The Filter

When each filter is called by Perl, a local copy of C<$_> will contain
the key or value to be filtered. Filtering is achieved by modifying
the contents of C<$_>. The return code from the filter is ignored.

=head2 An Example -- the NULL termination problem.

Consider the following scenario. You have a DBM database that you need
to share with a third-party C application. The C application assumes
that I<all> keys and values are NULL terminated. Unfortunately when
Perl writes to DBM databases it doesn't use NULL termination, so your
Perl application will have to manage NULL termination itself. When you
write to the database you will have to use something like this:

    $hash{"$key\0"} = "$value\0" ;

Similarly the NULL needs to be taken into account when you are considering
the length of existing keys/values.

It would be much better if you could ignore the NULL terminations issue
in the main application code and have a mechanism that automatically
added the terminating NULL to all keys and values whenever you write to
the database and have them removed when you read from the database. As I'm
sure you have already guessed, this is a problem that DBM Filters can
fix very easily.

## nullFilter

Hopefully the contents of each of the filters should be
self-explanatory. Both "fetch" filters remove the terminating NULL,
and both "store" filters add a terminating NULL.


=head2 Another Example -- Key is a C int.

Here is another real-life example. By default, whenever Perl writes to
a DBM database it always writes the key and value as strings. So when
you use this:

    $hash{12345} = "something" ;

the key 12345 will get stored in the DBM database as the 5 byte string
"12345". If you actually want the key to be stored in the DBM database
as a C int, you will have to use C<pack> when writing, and C<unpack>
when reading.

Here is a DBM Filter that does it:

## intFilter

This time only two filters have been used -- we only need to manipulate
the contents of the key, so it wasn't necessary to install any value
filters.

=head1 Using BerkeleyDB with MLDBM

Both BerkeleyDB::Hash and BerkeleyDB::Btree can be used with the MLDBM
module. The code fragment below shows how to open associate MLDBM with
BerkeleyDB::Btree. To use BerkeleyDB::Hash just replace
BerkeleyDB::Btree with BerkeleyDB::Hash.

    use strict ;
    use BerkeleyDB ;
    use MLDBM qw(BerkeleyDB::Btree) ;
    use Data::Dumper;

    my $filename = 'testmldbm' ;
    my %o ;

    unlink $filename ;
    tie %o, 'MLDBM', -Filename => $filename,
                     -Flags    => DB_CREATE
                    or die "Cannot open database '$filename: $!\n";

See the MLDBM documentation for information on how to use the module
and for details of its limitations.

=head1 EXAMPLES

TODO.

=head1 HINTS & TIPS

=head2 Sharing Databases With C Applications