Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Switch from DBI to DBIx::Class: thoughts?

by frew (Acolyte)
on Mar 16, 2009 at 20:41 UTC ( [id://751027]=perlquestion: print w/replies, xml ) Need Help??

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

Hello friends!

I have been using an ORM (DBIx::Class) on a new project at work and I've been bitten by the bug. I think that using an ORM would solve a lot of the maintainability issues that we are having with another long term project. So with that in mind I thought it would be nice to gradually convert from vanilla DBI and inline SQL to using DBIx::Class models.

Does anyone have any thoughts on how to go about migrating to an ORM? Is it worth the (significant) effort? Can we start small and only do files we touch after a certain date?

I'd appreciate any tips at all.


fREW Schmidt
  • Comment on Switch from DBI to DBIx::Class: thoughts?

Replies are listed 'Best First'.
Re: Switch from DBI to DBIx::Class: thoughts?
by bellaire (Hermit) on Mar 16, 2009 at 21:15 UTC
    The only thing that bothers me about DBIx::Class is, the last time I used it, when the operations you needed surpassed a certain level of complexity, you ended up still passing in SQL syntax in scalar references at certain points, for example when I wanted to select for a column which was within a particular range of values (dates). If you get to that point, you're losing out on the benefit of the abstraction because now you have to have familiarity with the plain SQL as well as the DBIx::Class abstraction. However, I don't know that my experience was typical, or even if I was doing things the right way. YMMV.

      I've bumped into that limitation in every ORM I've used, sooner or later. There is eventually no escaping the fact that you're not using the native language of your database. The main solutions I'm aware of are:

      1. Watch SQL gradually take over your application code as you bump into ever more dark corners where the abstraction doesn't hold up;
      2. Tuck your SQL code into methods so that things still looking shiny and ORM-y to users of your code;
      3. Give up on ORMs and use a phrasebook approach.

      1 and 2 are nearly the same, they just involve an executive decision about who has to look at SQL. Option 3 is a pretty significant shift that might not work on a project that already relies heavily on an ORM.

      I guess that means the main option is to suck in your gut and deal with SQL every once in a while. You can't escape it forever.

      Incidentally, I'm not trying to be mean or anything. I'm very sympathetic, just slightly charred from the many times I've seen my lovely abstractions break down in the face of cold cold reality.

        I agree that this is bound to happen. There are no perfect abstractions. But we do want to abstract commonly performed actions and tests. We could migrate away from an ORM and just use models that know how to do some SQL. The point isn't as much to get away from SQL (in my mind) as it is to have Models the represent our objects well. An ORM just makes that nicer for us.

        fREW Schmidt
      I guess it depends on how many complex versus simple queries you have in your application. In the applications I worked on the bulk of queries are really simple (at least below the threshold you mention above) - and justify a bit of more work for the complex ones.
Re: Switch from DBI to DBIx::Class: thoughts?
by Your Mother (Archbishop) on Mar 17, 2009 at 06:08 UTC

    My feedback about whether you should: Hells yeah!

    On a more sober note: If your DB layout is clean then you definitely should. If your data is messy and the sort of stuff that makes DB admins cringe then maybe not. Over the years the *only* things I have seen go on the mailing list with no good answers were because the underlying data design was fscked and something designed for clean, correct data design like DBIC just isn't set up to meet it in the middle.

    There is much more to be gained that simple object abstraction of a row. There's inflation, deflation, serialization, automatic adjunct/auxiliary data generation, validation, schema versioning, x-platform deployment, automatic fixtures, testing, resultset chaining, and more.

    To do legacy stuff: I'd auto-generate a DBIC schema (Result:: and ResultSet:: namespaces, which isn't in all the docs because it's pretty new but it rules). Then just give new code a shot via the new DBIC schema. Setting it up is trivial; here's a semi-tested snippet-

    use DBIx::Class::Schema::Loader "make_schema_at"; die "Give DB connection args! E.g.:\n", " dbi:mysql:someTable user password \n", " 'dbi:mysql:moo_moo;mysql_read_default_file=~/.my.cnf'\ +n" unless @ARGV; $ARGV[3] = { quote_char => "`" }; # Useful tidbit not (obvious) in the + docs. make_schema_at( $insert_schema_class, { components => [qw( SomethingYouUse )], quote_char => "`", dump_directory => $target_lib, use_namespaces => 1, }, \@ARGV );

    Then go with it for the next little something-something and see if it's fun or a drag. :)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://751027]
Approved by Corion
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2024-04-14 17:19 GMT
Find Nodes?
    Voting Booth?

    No recent polls found