Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pdcawley (485)

  (email not shown publicly)
AOL IM: pdcawley (Add Buddy, Send Message)

Journal of pdcawley (485)

Wednesday September 18, 2002
04:56 PM

Coo... have we done all that?

[ #7818 ]

James asked me to check out the slides for his Pixie presentation at YAPC, which he'll be giving tomorrow. Pixie is the Object Persistence tool that James, Leon and I have been working on for the past few months. (Although I think I've written the bulk of the code, because I've been the one who actually needs a working Pixie, the design has been very much a collaborative affair, and Pixie wouldn't have come about without James' original, very cunning idea about how to work out what needs storing.)

Now I've been aware as I've worked on it that it's doing some pretty cool stuff, but it's only when I read the presentation that I realised quite how cool it is already, and it's still got some way to go.

Right now, Pixie gives you:

  • Object persistence for virtually any object with a hash or array based representation. Without schemas
  • Object persistence for objects that use Regexp or simple scalar references, and don't hold any other 'out of band' information, but you have to do sub Class::px_is_storable { 1 }
  • Object persistence for any other kind of class you care to mention, provided those classes make use of Pixie's 'Complicity' features.
  • Automatic management of object locks, either exclusive, shared, or readonly, with unlocking handled correctly when an object goes out of scope.
  • Custom DESTROY behaviour for all objects managed by Pixie, without any reblessing, lexical hooks or whatever: If your objects already have DESTROY behaviour, that behaviour will be called transparently. I may be releasing a version of the code that does this, probably called 'Ref::Footnotes', but I'm not sure yet.
  • A test suite that uses characters from Buffy the Vampire Slayer (A small thing, but it is a product of members)

Yes, there are things it can't do: we don't have a query language (but, dammit, we don't want one, and if you do Pixie is subclassable); if your objects do tricks with weakrefs you'll probably have to make use of complicity; the documentation is currently lousy; the datastore isn't garbage collected (yet, that's what I'm working on at the moment, it's coming on nicely thanks) and the build process could use some work.

All in all, I think Pixie's a pretty impressive bit of software and, what's more, you can get a relatively recent version of it (released on Monday) from CPAN to play with. I commend it to you.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'm curious, how are you planning to use Pixie? It looks generally useful enough but I wonder what sort of system would critically depend on its functionality...


    • We're using it for session type work. Because Pixie can handle arbitrary objects we can save pretty much the entire state of an application between transactions without having to worry about packing and unpacking everything from some tiny session object. The complicity features came about because we've got some objects and applications within the framework that hold onto DBI handles and the like, which can't be directly stored.

      Pixie's lack of schemas means we can keep some flexibility in our object model
      • Interesting. What advantages does Pixie have over the typical tied MLDBM hash per session strategy? Over Apache::Session? Maybe you could add a comparison section to the Pixie docs outlining the similarities and differences between Pixie and other solutions.


        • What advantages do *any* object persistence tools have over MLDBM or Apache::Session? Pixie deals with real objects; the user doesn't have to worry about marshalling state. It does deferred fetching, allowing the user to build complex object webs without having to worry about fetching the world (until he needs to).

          Pixie works to make sure that there's only one 'live' instance of an object in play at any given time (and, with locking can be set up to ensure that this is the case across multiple processes).
          • MLDBM uses Storable to serialize Perl structures, so it handles objects just fine. However, your points about synchronized access to objects and object webs are well taken.