Does Item #1 mean the first list element returned by STORABLE_freeze?
return $serialized, $self->{locale}, $self->{tz}, \$self->{formatter};
Because, indeed it isn't a reference, but a scalar.
I have some code that is serializing items that have DateTime objects
(of course) and I'm seeing that message when running
my test suite.
I added this line above that line above in DateTime:
warn ">>>>$serialized\n";
And running my tests I see:
>>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
>>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
ok 6 - Fetched expected key
>>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
>>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
>>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
>>>>utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
ok 7 - Fetched data matches
>>>>utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
(in cleanup) Item #1 returned by STORABLE_freeze for DateTime
is not a reference at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_freeze.al) line 339 during global
destruction, at <....> line 327
Line 327 is
my $serialized = nfreeze( $data );
I'm a bit confused why it's only complaining on the last one --
STORABLE_freeze is seemingly returning the same (scalar) data.
It's expected that this nfreeze is happening in a DESTROY() (the data
gets serialized and stored upon destroy).
Is the destroy a red herring?
--
Bill Moseley
[email protected]
