Just A Summary

Piers Cawley Practices Punditry

The Authentication Fairy

If you haven’t yet read Ovid’s post about the ‘AuthenticationFairy’, you should. Go on, you can rejoin me below the fold for discussion of some scary Perl…

Apart from offering a very powerful way of thinking about Objects and OO analysis, Ovid touches on something that niggles me about Rails1; the way ActiveRecord works.

Yes, yes, ActiveRecord’s brilliant, as an implementation of the Active Record pattern, it’s pretty exemplary.

I just don’t like the pattern. Back when I was a dedicated Perl programmer, I worked on an object persistence system which Leon Brocard named “The Magic Data Pixie” – we generally just called it Pixie – which was a very different kind of persistence tool.

Pixie’s goal was to make objects persistent. All of them. Regardless of their source. You just wrote your application, connected your objects together appropriately, then threw a ‘top level’ object to the data pixie and asked it to store the object for you and associate it with a given key.

Later, you could ask pixie to fetch the top level object you’d stored, and just carry on using it as if it’d always been resident in memory. Pixie handled proxy object, deferred fetches from the database, all the backstage stuff needed to maintain the illusion that everything was resident in memory and always had been.

It wasn’t perfect, but we kept the illusion going; objects didn’t know, or care if they had been persisted, the data store was garbage collected (mark and sweep, triggered by asking Pixie to run a sweep for you), objects were unique – you’d never have two objects in memory with the same id.

Quite deliberately, we didn’t have a query language; the idea was that you got into the data store through known entry points and, if you needed to do searching or indexing or whatever, you could write your own. The plan was to discover what sort of searching would be needed, and implement that.

As ‘one to throw away’ I’m really rather proud of Pixie. It fell down on locking – we tried to add it later, and that really, really didn’t want to work. If I were starting with a clean sheet, I’d worry about that far earlier and probably try and use optimistic locking to implement something transaction – there’s at least one Smalltalk persistence engine that has some good ideas here, I just can’t remember what it’s called.

I’d also look at a hybrid scheme. Pixie was essentially one big table with an id column and a blob – not exactly scalable. With a sensible scheme for describing classes, it should be possible to have one big table for some objects and ActiveRecord type tables for things that you want to search. Jifty’s persistent objects do some very clever things in this regard.

Metadata would be useful in another respect too. ActiveRecord’s validations, errors and helpers like input 'variable', 'field' all use a pretty restricted set of ActiveRecord metadata. A class description language (or an appropriate set of class methods) that could implement compliant columns, attributes and the others could be very useful…

I suppose the question is, could I implement it? Pixie poked in some very odd corners of Perl to get the behaviour we needed. One example was the mementos that could replace themselves with the ‘real object’ they’d fetched from the database. They were all instances of Pixie::Cookie with an AUTOLOAD – perl’s equivalent of method_missing that went to the database for the data, populated its ‘instance variables’ and then changed its own class to ‘become’ an instance of the appropriate class.

Hmm… I feel the need for a spike…

1 There’s lots of stuff that niggles me about rails. Nothing that makes me want to throw it out and start using something else – yet, but I’m still waiting for Perl 6.

Published on Sun, 25 Mar 2007 07:41:00 GMT by Piers Cawley under , , . Tags ,

If you liked this article you can add me to Twitter
  • Gravatar

    By James Duncan Sun, 25 Mar 2007 21:52:46 GMT

    It did indeed poke in some very odd corners of Perl. I’ve often found myself thinking about Pixie, and those odd corners. Part of the problem was that we (and mainly you) had to dig very far and very deep to expose those odd corners of the language, and that prodding ended up getting in the way somewhat.

    I’ve been thinking about some of those problems a lot lately from a different angle — the need to store objects in a cloud that has a low management overhead for nodes, and need for the objects to remain query-able. I’ve come to a somewhat surprising set of ideas thus far, but my thinking is not yet complete…

  • Gravatar

    By Daniel Berger Mon, 26 Mar 2007 09:52:27 GMT

    Regarding your postscript, there are other frameworks besides Rails – Nitro and Camping, just to name a couple. And your comment about waiting for Perl 6 is orthogonal to Rails, since Ruby != Rails.

    Or do you think that the things that bug you about Rails are directly tied to limitations within Ruby itself? If so, I’d like to hear what they are.

  • Gravatar

    By Piers Cawley Wed, 28 Mar 2007 06:15:42 GMT


    There are some limitations in Ruby itself, but there are other issues with Rails that aren’t directly related to Ruby.

    The things that have me waiting for Perl 6, or that I miss from Perl 5 are:

    • Perl 6 Rules
    • The Parameter stuff. It sometimes seems like I’ve swapped unrolling @_ for unpacking an options hash.
    • my and its associated lexical scoping (and use strict)
    • Libraries from Damian Conway, Audrey Tang, Jesse Vincent, Abigail et al. Jifty, for instance, is going to prod some serious buttock in Perl 6.
    • Language malleability
    • Blocks anywhere – Smalltalk’s the real leader here

    As for limitations in the language. Well, I’ve implemented the Extract Method refactoring in pure Perl 5, I can’t work out where to start on that in Ruby. I’m not sure how to go about implementing something like Pixie in Ruby either; one of the key things we depended on was being able to write proxy objects that could change class and become the real object (though I think I can use some cunning Eigenclass hacks to get round that). Of course, this could simply stem from the fact that I’ve been using Perl for more than 10 years and Ruby for two.

  • Gravatar

    By Piers Cawley Wed, 28 Mar 2007 06:17:28 GMT

    James: I’m in London for the next London Ruby Users Group and heading back up on the 1430 train on Tuesday. Do you fancy doing meeting up for early dim sum and chatting about this? If nothing else, it’s been ages.

  • Gravatar

    By Daniel Berger Mon, 09 Apr 2007 11:10:01 GMT

    one of the key things we depended on was being able to write proxy objects that could change class and become the real object

    First, ick. Second, as you predicted, this is possible thanks to Florian Gross and Mauricio Fernandez via evil.rb. Take a look at Object.class=, among other evil things.


  • Gravatar

    By Piers Cawley Mon, 09 Apr 2007 11:56:45 GMT

    Yeah, but there’s good ick and there’s bad ick.

    The fact that they’re often the same ‘ick’ in different contexts is neither here nor there. I discovered, from a bit of fossicking around in my Squeak image, that Smalltalk has the delightful:

    anObject become: anotherObject

    which causes anObject and anotherObject to swap identities. Something like that would have been exceedingly handy while we were writing Pixie; if nothing else it would have eliminated a huge pile of code that dealt with the fact that there’s 101 different ways of implementing objects in Perl.

  • Gravatar

    By Daniel Berger Wed, 11 Apr 2007 12:56:08 GMT

    Upon further review it looks like Object#become was removed from evil.rb. I know there used to be an implementation, but I suspect it was removed because there were too many issues. If you search the ruby-talk archives for Object#become you’ll find some interesting tidbits.

  • Gravatar

    By William Harford Thu, 17 May 2007 14:58:21 GMT

    Check out REServe for smalltalk http://squeaksource.com/REServe.html and also for PHP http://code.google.com/p/phaux

    REServe allows you to store objects in a relational database like you would store objects in an object oriented database. It fully supports polymorphism, via a lookup table, as well as stores objects in a meaningful way (not just a blob). REServe also does provide a query language.

    The idea behind REServe was to leverage all the time and brain power that has gone into relational databases and create an object oriented data store.

Comment The Authentication Fairy

Trackbacks are disabled

Powered by Publify – Thème Frédéric de Villamil | Photo Glenn