plucky (3) Tangram::Type::Dump::Any.3pm.gz

NAME

       Tangram::Type::Dump::Any - Intuitive DataBase InterFace

SYNOPSIS

         # ... in a nearby Tangram::Schema structure ...
         SomeClass =>
           { fields =>
             { idbif => {
                   -options => { dumper => 'Data::Dumper',
                               },
                   some_field => undef,
                   some_property => undef,
                   some_attribute => undef,
                   each_one => undef,
                   gets => undef,
                   saved => undef,
               },
               string => {
                   cheese => undef,
               },
             },
           };

DESCRIPTION

       The idbif mapping type collates multiple data members into a single perl_dump (see
       Tangram::Type::Dump::Perl), storable (see Tangram::Type::Dump::Storable) or yaml (see
       Tangram::Type::Dump::YAML) column.

       For instance, with the schema definition in the example, all the columns in the example would be
       serialised via Data::Dumper.

       If you stored an object like this:

         $cheese = bless { cheese   => "gouda",
                           gets     => 6,
                           each_one => 9 }, "SomeClass";

       You would see something in your database similar to:

         /^'--v------v--------v----------------------------'^\
         | id | type | cheese | idbif                        |
         >----o------o--------o------------------------------<
         |  1 |   42 |  gouda | { gets => 6, each_one => 9 } |
         \_,--^------^--------^----------------------------._/

       (note: the actual output from your SQL Database client may differ from the above)

       So, if you're the sort of person who likes to set their attributes with accessors, but doesn't like the
       overhead this places on the RDBMS... then this may help.  Note: the real benefits of this mapping type
       are for when you're storing more complex data structures than "6" and "9" :-).

       You may prefer to use the default dumping type, which is storable.

   LINKS TO OTHER OBJECTS
       If Tangram encounters another object which is already in storage (ie, has been inserted via
       "$storage->insert($foo)"), then it will store a "Memento".  This memento includes the object ID, which is
       sensitive to schema changes (the ordering of classes in the schema).

       If the class implements a "px_freeze" and "px_thaw" function, then there will be a "Memento" that
       includes the class name of the object, and the data that was returned by the class' "px_freeze" method.
       To be reconstituted, it is called as:

         SomeClass->px_thaw(@data)

       See Tangram::Type::Dump for more details on the complicity API.

       Please set RETVAL to be the thawed object.  (that is, return a single scalar).

   BUT, I REALLY, REALLY HATE SCHEMAS!
       However, maybe you are one of those folk who don't like to declare their attributes, instead peppering
       hashes willy nilly, then there is another option.

       Instead of explicitly listing the fields you want, if you don't specify any fields at all, then it means
       save ALL remaining fields into the column.  For convenience, "-poof" is provided as a synonym for
       "-options", so you can write:

           { fields =>
             { idbif => { -poof => # There goes another one!
                          {
                          },
                        }
             },
           }

       [ You see, Tangram::Type::Dump::Any isn't actually an intuitive DB interface.  No, an intuitive DB
       interface is a user interface component, and that title is reserved for Visual Tangram.  VT expects to
       pick up the title with any luck by the end of the 21st century^W RSN!

       I Don't Believe In Fairies is actually what it stands for.  It's a completely arbitrary name; chosen for
       no reason at all, and certainly not anything to do with Pixie. ]