Because a hash reference is already a scalar, I'm assuming that you mean you want it into a scalar *string*. Here's one way that you can exploit a scalar reference to be used as a memory file, and write the output of Data::Dumper directly to that scalar as a string value.

use warnings;
use strict;

use Data::Dumper;

my $href = {
    a => 1,
    b => [
            2,
            3,
         ],
    c => {
            25 => 'y',
            26 => 'z',
         },
    d => 4,
};

my $memfile;

open my $mfh, '>', \$memfile or die $!;
print $mfh Dumper($href);
close $mfh;

print $memfile;
[download]

Output:

$VAR1 = {
          'c' => {
                   '25' => 'y',
                   '26' => 'z'
                 },
          'b' => [
                   2,
                   3
                 ],
          'd' => 4,
          'a' => 1
        };
[download]

Does the use of $memfile as a memory file actually buy you anything, stevieb? I can't see how what you have there differs from the simpler alternative:

use warnings;
use strict;

use Data::Dumper;

my $href = {
    a => 1,
    b => [
            2,
            3,
         ],
    c => {
            25 => 'y',
            26 => 'z',
         },
    d => 4,
};

my $text = Dumper ($href);
print $text;
[download]

What am I missing?

in using this method you might find this helpfull

local $Data::Dumper::Indent=0;
[download]

Hey huck,

If you're recommending that switch, could you please show us an example of it in use (ie. what happens when it's used), and let us know the purpose of using that var?

G'day 3dbc,

I'd take a look at the built-in module Storable.

It's DESCRIPTION starts:

"The Storable package brings persistence to your Perl data structures containing SCALAR, ARRAY, HASH or REF objects, ..."

And, right after that, the MEMORY STORE section begins:

"The Storable engine can also store data into a Perl scalar instead, to later retrieve them. ..."

Storable

Storable is ok for short-time storage, e.g. caching stuff that needs a long time to be recalculated. But DBI sounds like long-time storage. OS, platform, and Perl versions may change over time, and because Storable depends on all of these, that will break Storable.

Stuffing serialised perl data structures into a database does not sound sane. It means the database is not normalised. Ideally, all data would be stored in database-native formats.

Anyway, there are various other formats to serialise data structures that do not depend on the exact perl version, e.g. XML, JSON, YAML.

---

See also:

• Re: Perl Storable problem (i Think)
• Re^2: memory persistance
• Re^3: Portable datastore formats in core perl?
• Re^4: The safety of string eval and block eval.
• Re^2: Storing state of execution
• Re^2: Caching Format

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

my $param = join(q{, }, map{qq{$_ => $ref2->{$_}}} keys %$ref2);
[download]