Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Object Persistence, Moose and playing nicely with ActiveRecord

by pdcawley (Hermit)
on Sep 08, 2008 at 14:27 UTC ( #709776=perlquestion: print w/replies, xml ) Need Help??
pdcawley has asked for the wisdom of the Perl Monks concerning the following question:

Suppose for a moment that you'd been spending the last few years programming in Ruby using Rails. Suppose further that you'd got sufficiently hacked off with the framework that you were seriously considering switching back to something Perlish for adding new features (because, frankly, Moose is lovely) to your webapp.

How does one get Moosey goodness and persistent objects that won't require one to rejig the database schema?

Suppose that the application you're looking at extending takes advantage of ActiveRecord features like single table inheritance, composed_of and various other bells and whistles.

  • Comment on Object Persistence, Moose and playing nicely with ActiveRecord

Replies are listed 'Best First'.
Re: Object Persistence, Moose and playing nicely with ActiveRecord
by stonecolddevin (Vicar) on Sep 08, 2008 at 15:09 UTC

    DBIx::Class has all the ORM functionality that ActiveRecord has (and from what I can tell it's known to be faster as well.

    I'm surely going to get stoned for this, but Jifty is very similar to Rails in many ways, so if you're looking for a pretty easy transition, Jifty might be the way to go. The database/schema set up is nearly identical, and much of the Model coding styles are very much the same as well.

      Wow, all you have to do is say Jifty is like Rails and you get drugs? JIFTY IS LIKE RAILS JIFTY IS LIKE RAILS JIFTY IS LIKE RA- woah... pony...mmmmmmmmmmmmmmmm



Re: Object Persistence, Moose and playing nicely with ActiveRecord
by Corion (Pope) on Sep 08, 2008 at 14:31 UTC

    Suppose that I don't know anything about Ruby, Ruby On Rails or ActiveRecord except for the horror stories that roam the interwebs. How would you explain "single table inheritance", "composed_of" and "various other bells and whistles" in terms that make sense to the outside world?

    Basically, if you can tell us what the SQL statements are and possibly even how the object API is, maybe we can find equivalent things in the Perl world.

    Possibly, DBIx::Class does lots of what you want, but then again, I've become a friend of raw SQL for anything less trivial than updating a single column or row, because ORM wrappers don't work for me.

      Single table inheritance. You have a class, Document, stored in the documents (I know) table you have:
      package Review use Moose extends 'Document'
      The documents table has a set of columns which is the superset of attributes of Document and all its subclass and a type column which contains the name of the class for that row. Document->find finds Documents, Reviews and any other subclasses of document, Review->find finds only reviews (and any subclasses).

      Composed of: A way of getting round primitive obsession. You can declare something like:

      composed_of :price, :class_name => 'Money', :mapping => %w{cents currency}
      And ActiveRecord handles turning cents and currency columns into a Money object when the object is pulled out of the database breaking the price into cents and currency the the object's put back in there.

      Bells and whistles: Mostly to do with declaring relationships between classes with has_many/belongs_to etc. If you want me to regurgitate the ActiveRecord::Base documentation then I will, but it's far from being the world's best documentation in the first place and my paraphrasing skills are poor. Most of the perly ORMs appear to have sensible equivalents already so it won't be beyond my wit to sort out the mapping.

        There are inheritance modules for Class::DBI and Tangram, but I haven't seen any for Rose::DB::Object or DBIx::Class. It's a relatively easy thing to build though, just making classes for each type. The only tricky part is turning Documents into Reports, which I've implemented in my own Class::DBI stuff before by having the base class look at a type column and then instantiate an object of the right class with the current primary key.

        The rest of the stuff is standard issue ORM functionality that all the Perl ones have.

        I'm not aware of any Perl-ORM implementing Single Table Inheritance (or rather, Single Table Object Storage). I guess you can fake this by creating updateable views for all classes if your underlying DB supports that.

        For composition, I think DBIx::Class (like Class::DBI) has inflation/deflation links which can be used to instantiate the appropriate objects for fields. But I haven't used either.

Re: Object Persistence, Moose and playing nicely with ActiveRecord
by zby (Vicar) on Sep 08, 2008 at 14:52 UTC
    As Corion said this is a bit under specified - but DBIx::Class can be used with any DB schema - it does not impose any naming conventions, you can use composed (multi column) primary keys and I am pretty sure you can do single table inheritance with it. Unfortunately you'll need to wait a bit for the complete moosification of DBIx::Class. You can also have a look at Fey::ORM - which is Moose based, but is still experimental.
      Waiting for moosification of DBIx::Class - I did find something demonstrating Moose and DBIx::Class playing together, but the repeated declarations gave me the shudders. It seems as if it shouldn't be hard to extend Moose's declaration syntax to implement something like MooseX::DBI, but it's one of those Simple Matter Of Programming things isn't it? Easy in principle, but tedious in practice.
        I did find something demonstrating Moose and DBIx::Class playing together, but the repeated declarations gave me the shudders.

        You can take a look at the as-yet-unreleased MooseX::DBIC here which provides a Moose-ish layer over the top of DBIx::Class and (IMO at least) nicely merges the strengths of DBIx::Class with the meta-goodness of Moose. It is not 100% feature complete, there are still some bridging between more obscure DBIC features to be done. But fwiw, this is currently used in a production application and so far so good.

Re: Object Persistence, Moose and playing nicely with ActiveRecord
by UVB (Acolyte) on Jan 12, 2012 at 22:17 UTC
    KiokuDB looks like a potential solution for this: KiokuDB

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://709776]
Approved by Corion
Front-paged by Arunbear
[ambrus]: ad code examples.
[ambrus]: I'm not trying to recommend PHP, but I think it has way too bad a name because of its past.
[ambrus]: This is different from MS Word, which was already a good editor in the pre-unicode days (in word for windows versions 2 and 6, which ran on windows 3 but also on windows 95), only it wasn't trying to solve the task of writing maths papers back then.
[Discipulus]: ah ok, sounds reasonable; with no fear: Perl all life long
[ambrus]: Mind you, LaTeX is currently still useful for writing math paper or snippet content without styling in such a way that the
[ambrus]: formatting conventions of a journal or website can be quickly applied to it, and MS Office and LibreOffice has not quite solved this (although it's better for this than it used to be),
[ambrus]: which is sort of a drawback compared to the ages of typewritten manuscripts representing content only to which the typesetter applies formatting, but that process required much more manual labor.
[ambrus]: If you want to typeset a manuscript, you can still do much less work then in the manual typesetting ages and get good formatting.
[ambrus]: All with only cheap modern computers and software.
[ambrus]: Something you can have at home and your corner print shop, without a whole printing press's worth of equipment.

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (12)
As of 2017-09-26 11:12 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (293 votes). Check out past polls.