All the Perl that's Practical to Extract and Report

Coo... have we done all that?

pdcawley on 2002-09-18T21:56:02

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 London.pm 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.

Curiosity

samtregar on 2002-09-18T22:39:02

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...

-sam

Re:Curiosity

pdcawley on 2002-09-19T04:59:54

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 without having to remember that a change in one object means changing the schema as well, and then rebuilding the database (major changes once something is in production will obviously require database conversion, but during the development phase we can keep things as fluid as possible).

Re:Curiosity

samtregar on 2002-09-19T05:16:17

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.

-sam

Re:Curiosity

pdcawley on 2002-09-19T08:31:08

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).

Right now, I'm working on tools that will allow the repository to be garbage collected using a mark & sweep based approach. Next on the list is the possibility of 'complicit indices', paving the way to a restricted query interface (which should be good enough for *most* queries), but that's going to be some way in the future because I don't have a need for it right now.

Re:Curiosity

samtregar on 2002-09-19T15:08:18

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.

Thanks,
-sam