I have this old method in Handel that clones a storage class instance by first dereferencing the DBIC schema/DBI handle to keep Clone from bitching, calling Clone::clone, then stuffing the schema back in the original object.
sub clone { my $self = shift;
Handel::Exception::Storage->throw( -details => translate('NOT_CLASS_METHOD') ) unless blessed($self); ## no critic
# a hack indeed. clone barfs on some DBI inards, so lets move out the # schema instance while we clone and put it back if ($self->_schema_instance) { my $schema = $self->_schema_instance; $self->_schema_instance(undef);
my $clone = Clone::clone($self);
$self->_schema_instance($schema);
return $clone; } else { return $self->SUPER::clone; }; };
Just for giggles, using Storable::dclone works just dandily, but I didn't use it in 5.8 because for one line of code, it's a pain in the ass as a prereq, esp on windows sometimes.
This would be the Storable
that has been in core as of 5.8.0? And built and installed by default? So what's the problem with making it a prerequisite?
Re:Storable prereq
barbie on 2008-08-19T11:18:28
Can't speak for Chris, but for me it is horribly broken if at any time you upgrade. Anything made with a specific version of Storable will ONLY work with that version of Storable. The data file also breaks between different OSs even with the same version. In a previous project I ended up moving to XML because it actually was persistent!
It may have changed since, but these days I avoid it wherever possible.
Re:Storable prereq
nicholas on 2008-08-19T11:46:47
The data file also breaks between different OSs even with the same version.
The default file format is architecture specific, for speed. If you want to move things between systems (or
perl
configurations) you wantnstore
ornfreeze
.As to between versions - yes, there was a bug in the version checking code, based on the intent. It used to (wrongly) insist that the major and minor versions of the file were identical, and as the minor version had often been bumped, that meant problems. Some time ago (I forget when) that was fixed so that only the major versions had to match - now, as long as the file doesn't use any tag that the receiver doesn't understand, it should work.
As to the jk2addict's original problem -
Storable::dclone
has to be running on the same architecture, because it has to be running in the same process, so the issues you found can't affect it.Re:Storable prereq
jk2addict on 2008-08-20T00:31:28
This is also the same Storable that constantly dies of gets wrong cloning with "Can't store CODE items" errors. Another problem Clone::clone never has.