morgon has asked for the wisdom of the Perl Monks concerning the following question:


I need to persist Moose-based objects in an Oracle-database and wonder wether to use an established ORM (which one and why) or roll my own.

Ideally I would like to use a ORM-system that harnesses the features of Moose (Traits etc) but I need something where I can use hand-crafted SQL as well in case I have to optimize for performance.

As this will be a mission-critical system I would prefer something solid and proven over something cool.

Many thanks!

Replies are listed 'Best First'.
Re: looking for a OR-mapper for Moose
by stvn (Monsignor) on Apr 14, 2009 at 00:26 UTC

    DBIx::Class is not (yet) written in Moose, but many people have used Moose and DBIx::Class together quite successfully. And if your looking for maturity and stability in an ORM, DBIx::Class is the right choice (no offense to Fey::ORM, but as the author says in the docs, it is still kinda new).

Re: looking for a OR-mapper for Moose
by Sartak (Hermit) on Apr 13, 2009 at 21:48 UTC

    Fey is a very Moosey SQL generator, upon which Fey::ORM is built. It's written by Dave Rolsky, a core Moose developer, who writes bulletproof code.

    That said, its documentation does warn you that "This is still very new software, and APIs may change in future releases without notice. You have been warned."

    I don't know what your requirements are, but Fey is definitely Moosey and is probably solid enough to use.

      "... who writes bulletproof code"

      Well, someone was posting on Perlmonks while high, clearly.

        By bulletproof he means teflon (in the 50 Cent sense of the word) and by teflon he means slippery and by slippery he means sloppy and by sloppy he means ... well ... bulletproof.

        I calls em like I sees em.

        I was about to defend Dave. That's what I get for keeping track of usernames. Pretty slippery. I mean bulletproof. 180 bulletproof...

        I've always preferred the term bullet-resistant, myself.

        G. Wade
Re: looking for a OR-mapper for Moose
by jrockway (Acolyte) on Apr 13, 2009 at 21:55 UTC

    You should take a look at KiokuDB. It is probably what you want, and although it is rather new, it is in production in some pretty important apps.

    It is an object database rather than an ORM, which means that you can't edit the database from outside of the Perl world. If you just want to query the objects with SQL, though, you can use GIN to index the necessary attributes in your app. (The docs describe this in detail, it is a common thing to do.)

    This probably sounds "different" than what you are used to, but KiokuDB has made our apps a lot cleaner than a relational database + DBIC, and in many cases, more efficient. You will also have a variety of choices for backends; you can use Oracle if you want, but you can also use Berkeley DB, CouchDB, Amazon SimpleDB, and so on... without changing your app's code.

Re: looking for a OR-mapper for Moose
by Corion (Patriarch) on Apr 13, 2009 at 21:14 UTC
    As this will be a mission-critical system I would prefer something solid and proven over something cool.

    And you're using Moose?

    I'm unaware of a DBI backend for MooseX::Storage, but it shouldn't be hard to write one. You "just" have to think about how you want to implement the storage of traits, as a separate table or within the per-class-table. Adding hand-written SQL will be hard, as always.

      Moose has been around for three years. It's being used in production by several companies with household names, as well as perhaps hundreds of smaller organizations and countless end-users.

      Its theoretical foundation goes back probably nearly thirty years.

      Is there anything in particular that makes you question Moose's provenness and solidity?

        Being developped for three years means nothing - Perl6 has been in development for almost 10 years now.

        I'm not sure what you mean by "household names", but I don't think that I can ask my mother about any Moose-using-Perl company and get a set of answers that contains any of the names you seem to have in mind.

        I guess that we're both aware of many things whose theoretical foundations go back far longer than 30 years and that still are not a good idea.

        I question Mooses provenness because it's simply too young and while using it, I've seen that it's nice conceptually but doesn't buy me much over plain objects. I see it much like the Inside-Out fad that produced a slew of bad prerequisites and little else.

        Of course it's always questionable to use a fancy new technology for a mission critical part.