To your specific questions, this is a good way to do it but don't put much data in the serialized object or it will start to get slow. You should only put things like keys into other tables in there (shopping cart ID, user ID). You don't need to get Storable to read from the database. You just give it a scalar containing serialized data that you fetched from the database. Storable is available from ActiveState's PPM system and I think they ship it with their distribution. There are other pre-built Perl distros for Win32 that have it, like the one Randy Kobes builds. Storable will be part of the standard library starting in perl 5.8.

2. Hmm, see the Storable documentation, all of it (there is freeze/thaw to do it from memory, meaning a scalar, which is what you're looking for, or should've been)

3. Hmm, can you say PPM my boy, can you (1.012 seems recent enough for me as well as 1.0.10, but in case you need 2.4 or whatever, i'll didtry'n'compile and put it on my ppm repository)?

 

______crazyinsomniac_____________________________ Of all the things I've lost, I miss my mind the most. perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

#Freeze the object
my $data = eval { unpack ('h*', Storable::nfreeze($object))} ;

# ORACLE SPECIFIC
# create a hash containing specifying to Oracle what
# sort of data it will need to store. 112 is the value
# for a CLOB, 113 is the value for a BLOB.
# FIXME: make this a BLOB when DBD::Oracle supports that

my %hash = (ora_types => 112, ora_field => 'data');
# END ORACLE

# insert our values into the table
my $query = "INSERT INTO $table (jobID, data) VALUES ('$jid','$data')"
+;

$db_handle->execute($query, \%hash);
 
# To thaw (after retrieving from the DB)
my $object = eval { Storable::thaw(pack('h*',$data)) }
[download]

This may not be the best for your situation, especially since others have suggested off the shelf solutions that appear to address your needs, but this approach does work.

Update: perrin++. I came up with this scheme in early '00, and at that time BLOBS weren't implemented, or at least not in the version of DBD::Oracle we were using. I guess now I can go back and fix the FIXME's :)

Hmmm, DBD::Oracle has support for BLOB data. We used it that way at eToys two years ago. We used the bind_param call instead of passing the parameters to execute. You could also try using a LONG if you can't get BLOB to work.

my %hash = (ora_types => 112, ora_field => 'data');

Rather than using the less obvious 112, this may make the code a bit more self-documenting:

use DBD::Oracle qw(:ora_types);
...
my %hash = (ora_types => ORA_CLOB, ora_field => 'data');
[download]

--Dave

3. If you can't get Storable to work, you might try Data::Dumper, which is in the standard distro.

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]

In case you intend to send frozen data between machines, here are two details I've run into. Both of these have caused silent and/or strangely located failures in the past.

Use nfreeze(), not freeze(). Otherwise you may run into problems if both machines don't agree on a byte order.

Data frozen with one version of Storable may not thaw properly with another. Be sure both ends are running identical versions.

-- Rocco Caputo / poe.perl.org / poe.sf.net

I use a very similar method, cept for extra security I also use the stuff from http://pajhome.org.uk/crypt/index.html to get the user submitted pwd across safely (I don't have SSL).

I use BerkeleyDB for the DB backend && it goes something like this:
$my_cool_db{'some_key'} = freeze({what=>'ever'}); my $var = thaw($my_cool_db{'some_key'});