Provided by: libtie-persistent-perl_1.00-1_all bug

NAME

       Tie::Persistent - persistent data structures via tie made easy

VERSION

       1.00

SYNOPSIS

        use Tie::Persistent;

        tie %DB, 'Tie::Persistent', 'file', 'rw'; # read data from 'file'

        (tied %DB)->autosync(1);       # turn on write back on every modify

        # now create/add/modify datastruct
        $DB{key} = "value";
        (tied %DB)->sync();            # can be called manually

        untie %DB;                     # stores data back into 'file'

        # read stored data, no modification of file data
        tie %ReadOnly, 'Tie::Persistent', 'file';
        foreach (keys %ReadOnly) {
          print "$_ => $ReadOnly{$_}\n";
        }
        untie %ReadOnly;               # modifications not stored back

DESCRIPTION

       The Tie::Persistent package makes working with persistent data real easy by using the
       "tie" interface.

       It works by storing data contained in a variable into a file (not unlike a database). The
       primary advantage is speed, as the whole datastructure is kept in memory (which is also a
       limitation), and, of course, that you can use arbitrary data structures inside the
       variable (unlike DB_File).

       Note that it is most useful if the data structure fits into memory.  For larger data
       structures I recommend MLDBM.

       If you want to make an arbitrary object persistent, just store its ref in a scalar tied to
       'Tie::Persistent'.

       Beware: not every data structure or object can be made persistent.  For example, it may
       not contain GLOB or CODE refs, as these are not really dumpable (yet?).

       Also, it works only for variables, you cannot use it for file handles.

       [A persistent file handle? Hmmm... Hmmm! I've got an idea: I could start a server and send
       the file descriptor to it via ioctl(FD_SEND) or sendmsg.  Later, I could retrieve it back,
       so it's persistent as long as the server process keeps running.  But the whole file handle
       may contain more than just the file descriptor.  There may be an output routine associated
       with it that I'd somehow have to dump.  Now let's see, there was some way to get the
       bytecode converted back into perl code... <wanders off into the darkness mumbling> ... ]

PARAMETERS

       "tie" %Hash,   'Tie::Persistent', file, mode, other...;

       "tie" @Array,  'Tie::Persistent', file, mode, other...;

       "tie" $Scalar, 'Tie::Persistent', file, mode, other...;

       file
           Filename to store the data in. No naming convention is enforced, but I personally use
           the suffix 'pd' for "Perl Data" (or "Persistent Data"?). No file locking is done; see
           the section on locking below.

       mode (optional)
           Same as mode for POSIX fopen() or IO::File::open. Basically a combination of 'r', 'w',
           'a' and '+'. Semantics:

            'r' .... read only. Modifications in the data are not stored back
                     into the file. A non-existing file gives an error. This is
                     the default if no mode is given.

            'rw' ... read/write. Modifications are stored back, if the file does
                     not exist, it is created.

            'w' .... write only. The file is not read, the variable starts out empty.

            'a', '+' ... append. Same as 'w', but creates numbered backup files.

            'ra', 'r+' ... Same as 'rw', but creates numbered backup files.

           When some kind of write access is specified, a backup file of the old dataset is
           always created. [You'll thank me for that, believe me.]  The reason is simple: when
           you tie a variable read-write (the contents get restored from the file), and your
           program isn't fully debugged yet, it may die in the middle of some modifications, but
           the data will still be written back to the file, possibly leaving them inconsistent.
           Then you always have at least the previous version that you can restore from.

           The default backup filenames follow the Emacs notation, i.e. a '~' is appended; for
           numbered backup files (specified as 'a' or '+'), an additional number and a '~' is
           appended.

           For a file 'data.pd', the normal backup file would be 'data.pd~' and the numbered
           backup files would be 'data.pd~1~', 'data.pd~2~' and so on. The latest backup file is
           the one with the highest number. The backup filename format can be overridden, see
           below.

       other (optional, experimental)
           This can be a reference to another (possibly tied) variable or a name of another
           tieable package.

           If a ref is given, it is used internally to store the variable data instead of an
           anonymous variable ref. This allows to make other tied datastructures persistent, e.g.
           you could first tie a hash to Tie::IxHash to make it order-preserving and then give it
           to Tie::Persistent to make it persistent.

           A plain name is used to create this tied variable internally. Trailing arguments are
           passed to the other tieable package.

           Example:

            tie %h, 'Tie::Persistent', 'file', 'rw', 'Tie::IxHash';

           or

            tie %ixh, 'Tie::IxHash';
            tie %ph,  'Tie::Persistent', 'file', 'w', \%ixh;
            # you can now use %ixh as an alias for %ph

           NOTE: This is an experimental feature. It may or may not work with other Tie::
           packages. I have only tested it with 'Tie::IxHash'.  Please report success or failure.

LOCKING

       The data file is not automatically locked. Locking has to be done outside of the package.
       I recommend using a module like 'Lockfile::Simple' for that.

       There are typical two scenarios for locking: you either lock just the 'tie' and/or 'untie'
       calls, but not the data manipulation, or you lock the whole 'tie' - modify data - 'untie'
       sequence.

KEEPING DATA SYCHRONIZED

       It often is useful to store snapshots of the tied data struct back to the file, e.g. to
       safeguard against program crashes.  You have two possibilities to do that:

       •   use sync() to do it manually or

       •   set autosync() to do it on every modification.

       Note that sync() and autosync() are methods of the tied object, so you have to call them
       like this:

        (tied %hash)->sync();

       and

        (tied @array)->autosync(1);  # or '0' to turn off autosync

       There is a global variable $Autosync (see there) that you can set to change the behaviour
       on a global level for all subsequent ties.

       Enabling autosync of course means a quite hefty performance penalty, so think carefully if
       and how you need it.  Maybe there are natural synchronisation points in your application
       where a manual sync is good enough.  Alternatively use MLDBM (if your top-level struct is
       a hash).

       Note: autosync only works if the top-level element of the data structure is modified.  If
       you have more complex data structures and modify elements somewhere deep down, you have to
       synchronize manually.  I therefore recommend the following approach, especially if the
       topmost structure is a hash:

       •   fetch the top-level element into a temporary variable

       •   modify the datastructure

       •   store back the top-level element, thus triggering a sync.

       E.g.

         my $ref = $Hash{$key};      # fetch substructure
         $ref->{$subkey} = $newval;  # modify somewhere down under
         $Hash{$key} = $ref;         # store back

       This programming style has the added advantage that you can switch over to other database
       packages (for example the MLDBM package, in case your data structures outgrow your memory)
       quite easily by just changing the 'tie' line!

CONFIGURATION VARIABLES

       $Tie::Persistent::Readable controls which format to use to store the data inside the file.
       'false' means to use 'Storable', which is faster (and the default), 'true' means to use
       'Data::Dumper', which is slower but much more readable and thus meant for debugging.  This
       only influences the way the datastructure is written, format detection on read is
       automatic.

       $Tie::Persistent::Autosync gives the default for all tied vars, so modifying it affects
       all subsequent ties.  It's set to 'false' by default.

       $Tie::Persistent::BackupFile points to a sub that determines the backup filename format.
       It gets the filename as $_[0] and returns the backup filename. The default is

        sub { "$_[0]~"; }

       which is the Emacs backup format. For NT, you might want to change this to

        sub { "$_[0].bak"; }

       or something.

       $Tie::Persistent::NumberedBackupFile points to a sub that determines the numbered backup
       filename format. It gets the filename and a number as $_[0] and $_[1] respectively and
       returns the backup filename. The default is

        sub { "$_[0]~$_[1]~"; }

       which is the extended Emacs backup format.

NOTES

       •   'Tie::Persistent' uses 'Storable' and 'Data::Dumper' internally, so these must be
           installed (the CPAN module will do this for you automatically).  Actually, 'Storable'
           is optional but recommended for speed.

       •   For testing, I use 'Tie::IxHash', but 'make test' still does some tests if it is not
           installed.

       •   There are two mailing lists at SourceForge.net:

           http://lists.sourceforge.net/mailman/listinfo/persistent-announce for announcements of
           new releases.

           http://lists.sourceforge.net/mailman/listinfo/persistent-discuss for user feedback and
           feature discussions.

       •   The package is available through CPAN and SourceForge.net
           http://sourceforge.net/projects/persistent/

       •   There is an initiative at SourceForge.net to get authors of persistence-packages of
           any kind to talk to one another.  See http://sourceforge.net/projects/POOP/

BUGS

       Numbered backupfile creation might have problems if the filename (not the backup number)
       contains the first six digits of the speed of light (in m/s).

       All other bugs, please tell me!

AUTHORS

       Original version by Roland Giersig <RGiersig@cpan.org>

       Benjamin Liberman <beanjamman@yahoo.com> added autosyncing and fixed splice.

COPYRIGHT

       Copyright (c) 1999-2002 Roland Giersig. All rights reserved.  This program is free
       software; you can redistribute it and/or modify it under the same terms as Perl itself.

SEE ALSO

       Storable, Data::Dumper, MLDBM.