in reply to Burned by Storable

What's the fracking point? What purpose does Storable serve if one can't rely on it to recover the data again?

The point is to know the limitations of your tools and to keep your tools current. 

Fri May 17 22:48:59 BST 2002   Nicholas Clark <nick@ccl4.org>

    Version 2.0, binary format 2.5 (but writes format 2.4 on pre 5.7.3
+)

        The perl5 porters have decided to make sure that Storable stil
+l
        builds on pre-5.8 perls, and make the 5.8 version available on
+ CPAN.
        The VERSION is now 2.0, and it passes all tests on 5.005_03, 5
+.6.1
        and 5.6.1 with threads. On 5.6.0 t/downgrade.t fails tests 34 
+and 37,
        due to a bug in 5.6.0 - upgrade to 5.6.1.

        Jarkko and I have collated the list of changes the perl5 porte
+rs have
        from the perl5 Changes file:

        - data features of upcoming perl 5.8.0 are supported: Unicode 
+hash
          keys (Unicode hash values have been supported since Storable
+ 1.0.1)
          and "restricted hashes" (readonly hashes and hash entries)
        - a newer version of perl can now be used to serialize data wh
+ich is
          not supported in earlier perls: Storable will attempt to do 
+the
          right thing for as long as possible, croaking only when safe
+ data
          conversion simply isn't possible. Alternatively earlier perl
+s can
          opt to have a lossy downgrade data instead of croaking
        - when built with perls pre 5.7.3 this Storable writes out fil
+es
          with binary format 2.4, the same format as Storable 1.0.8 on
+wards.
          This should mean that this Storable will inter-operate seaml
+essly
          with any Storable 1.0.8 or newer on perls pre 5.7.3
        - dclone() now works with empty string scalar objects
        - retrieving of large hashes is now more efficient
        - more routines autosplit out of the main module, so Storable 
+should
          load slightly more quickly
        - better documentation
        - the internal context objects are now freed explicitly, rathe
+r than
          relying on thread or process exit
        - bugs fixed in debugging trace code affecting builds made wit
+h 64 bit
          IVs
        - code tidy-ups to allow clean compiles with more warning opti
+ons
          turned on avoid problems with $@ getting corrupted on 5.005_
+03 if
          Carp wasn't already loaded
        - added &show_file_magic, so you can add to /etc/magic and tea
+ch
          Unix's file command about Storable files

        We plan to keep Storable on CPAN in sync with the Perl core, s
+o
        if you encounter bugs or other problems building or using Stor
+able,
        please let us know at perl5-porters@perl.org
        Patches welcome!

[download]

Replies are listed 'Best First'.
Re^2: Burned by Storable
by ruzam (Curate) on Jun 11, 2008 at 14:10 UTC
    My bad for not knowing the limitation of the tool.

    But I have no control over what version of the tool my application will encounter in the wild. I expect my application to run on any reasonably current Perl installation (old versions or not). I don't expect old versions of Storable to completely dump on a version change without some kind of backward compatibility armour built in from the get go. The fact that this is addressed in newer versions of Storable does not fix the already broken world that has been created around it.

    I know I will never trust Storable to use it again. If I could, I'd vote it off the 'Perl core' island.
[reply]
      I will never trust Storable to use it again. If I could, I'd vote it off the 'Perl core' island.

      Heh! You know, many of the porters feel the same way. It took a tremendous amount of effort to get it compiling and testing perfectly on all the various platforms that Perl runs on. Compiler idiosyncrasies make it particularly difficult to get right each time. Changing a preprocessor macro to work around the damage in one compiler made it break in another.

      And it continues to soak up developer effort, as time goes by. On the other hand, it's nice to have a big hairy XS module lying around so people can point to and say "oh no! not again!" whenever someone calls for another large XS module to be pulled into the core.

      • another intruder with the mooring in the heart of the Perl

[reply]
      But I have no control over what version of the tool my application will encounter in the wild.
      To a certain degree, this will be a problem with any module you use. Versions change, internals change, and incompatibilities creep in even when they aren't intended. The only way to be sure your application will work is to bundle specific versions of the modules it needs. This isn't so much a perl thing as a general issue with componentized software.

      In the case of core modules, you at least have a simpler target. You can test against the specific perl versions you want to support. But even so, distributions will modify them, people will install newer versions for features they need, etc.

      By the way, Storable rocks. It's massively faster than Data::Dumper, highly cross-platform when you store in network order, and as mentioned elsewhere the newer versions try hard to work across version and format changes. It was a great day for perl when we got a fast serialization mechanism in the core and I'd be very sorry to see it go.

[reply]

      You can always identify your environment your application will run in. Take a look at CPAN, part of what it does is looking at what modules are installed and what versions. Depending on the config, it will upgrade or install other Perl packages as needed. If it did not, CPAN would be a little more than a fancy file copy utility.

      Now if you don't want to work with Storable, that is fine, but what happens when another module that you depends on has issues because of different features from version to version? Are you going to curse that module too or are you going to do something about it?

      Take a look at Module::Build and consider how it handles installing modules and maybe you can come up with a better solution than excommunicating Storable.

[reply]

In Section Meditations