bionic (3) Tie::Persistent.3pm.gz

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 (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.