Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

hi all,

i'm working on an application handling with rather complicated data structures. in order to keep database tables concise, i decided to put most of the volatile data into a large hashref, which i then freeze via Storable.pm and store them into a BLOB column.

the funny thing is, that now, when trying to retrieve the original data, i get the following error message:

Not a scalar string at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 363

my idea is, that this might be the result of using a blob. but before i start writing a script that reads the blobs and tries to store them into text columns, i thought, i better ask you.

i'm using Perl 5.8.4 on a debian-testing system, Storable version is 2.12, MySQL 4.1.11.

any clues will be appreciated, many thx in advance.

Replies are listed 'Best First'.
Re: Storable & MySQL: BLOB or TEXT?
by bart (Canon) on Jun 29, 2005 at 07:10 UTC
    It does look like data corruption to me, but I'm not sure in what way. Perhaps the data is truncated. Perhaps it's something else still.

    Try, in a test database, to store some frozen data, retrieve it immediately, and compare the two (thus, both in frozen state), trying to figure out in what way it got corrupted —if it even did get corrupted.

Re: Storable & MySQL: BLOB or TEXT?
by anonymized user 468275 (Curate) on Jun 29, 2005 at 08:06 UTC
    Although it sounds from what you say that a hash reference is going into storage and an attempt is being made to read it out as a plain hash...

    We'd still need to see the code to be sure.

    One world, one people

Re: Storable & MySQL: BLOB or TEXT?
by radiantmatrix (Parson) on Jun 29, 2005 at 16:31 UTC
    I don't have time to refresh myself on Storable, but IIRC it dumps the data to text. A BLOB is a Binary Large OBject -- if you are storing text, and not binary data, then a TEXT element is probably better.

    However, you should be able to use a BLOB, but check to make sure your encoding is the same on the way in and on the way out. MySQL can "cast" the encoding for a client depending on how it is configured.

    Yoda would agree with Perl design: there is no try{}