I second this suggestion. Every time I read something in Conway's book and had a question, it would almost always be answered in the next section or chapter. It's also worth the buy for the investigation into class creation modules, too.

FreezeThaw works, but it can get VERY slow when you have a lot of hash keys.

Storable is superb, really a reference implementation. It is by the FreezeThaw author, but in C, and much faster. I think it should be a core perl module: serialization is becoming important nowadays.

Other possibilities: Yaml, XML::Dumper ...

General warning. I don't think there is yet a way to serialize coderefs, compiled regex's, or (unsurprisingly) handles. These can bite you in the bum sometimes.

dave hj~

Please note: there are Problems with XML::Dumper that AFAIK have not yet been resolved by the author.

...Guv

Good point. I also forgot about Data::DumpXML which I have used once or twice and seemed cool. But unless you need to use XML, I'd stick with Storable.

dave hj~

I've been working on a very similar problem, which I described briefly last week in Serializing CODE References. I've found that the Storable module works very well, however I believe that FreezeThaw will do what you require also. Storable has a better object oriented interface, if that's a factor in your decision.

Have you looked at SPOPS available at www.openinteract.org ?
It offers security as well as object persistence.

Cheers
Cheshire Cat

Try Storable; it permits saving and restoring arbitrarily complex nested structures.

Update: now I see that fever has already suggested this.

dmm

If you GIVE a man a fish you feed him for a day
But, TEACH him to fish and you feed him for a lifetime

I believe Data::Dumper is what your're looking for.

More specifically, the code is an MP3 server that goes and gets a playlist from a DB (all a playlist is is a bunch of fully qualified mp3's, one per line in a text file).

My playlists are generated by getting a list of mp3's storing them in an array, freezing (using Storable) the array, unpacking it to hex to remove any naughty characters, then storing in a RDMBS using DBI.  BINDVAR=> unpack("H*",freeze(\@{$params{PLAYLIST}}))

My server then does the reverse. It goes and gets the playlist, packs it pack up, thaws it, and the result is the same array I put in there when the playlist was generated.

sub {
..
..
    my @ary = $sth->fetchrow_array;
..
..
    my $retval =  thaw(pack("H*", @ary) );
    return @{$retval}
}
[download]

I'm currently working on a module that will do specifically what you are after (persistant storage in a db) to hone my OOP skills, so if you have any suggestions, /msg me, I'm open to ideas.

Monks,

Thanks for all your input on this topic. Storable has certainly solved my initial requirements.

The next challenge is that one of my structures contains coderefs. This could prove interesting. :-)

rW

The next challenge is that one of my structures contains coderefs. This could prove interesting. :-)

Can you turn those coderefs into methods and simply rebless and object into resurrection?

princepawn wrote:
> Can you turn those coderefs into methods and simply rebless and object into resurrection?

In this instance, no (nice idea though :-)). The coderefs here are closures containing info private to the object. Hence they do not want to be available to other objects in the same class.

I have a workaround, based on keeping a scalar alongside the coderef, which holds the code in string form. These are kept together in a code object. I am using storeable's STORABLE_freeze and STORABLE_thaw hooks to provide my own serialisation of said objects. This is working fine.

I am tempted to publish when I have some complete, working code.

rW