use Perl

• Great Points (Score:2)

  by Ovid (2709)

  When people talk about ORMs, I think they're generally looking at them the wrong way. The more I work with them, the more I think that trying to marry an class and a table is a terrible idea. I recently worked on a system where I could do something like this:

  $server->disable;

  That mapped to a table representing dedicated server, but that class had several other ORM classes it needed to interact with. That particular method hid tons of complexity behind it, including logging, deallocating IP addres
  • Re: (Score:1)

    by Aristotle (5147)

    That sounds very much like how I think of DBIx::Class. Have you looked at it? I don’t think of DBIC as an ORM so much as I think of it as an OO API for SQL. Its basic unit is the result set – in other words, an OO wrapper around an SQL query. The main win for me is that I can accumulate conditions into queries (including composing result sets into one another) and let DBIC build the resulting SQL for me, instead of having to manually write template-ish SQL-generating logic for highly parametrisa
    • Re:Great Points (Score:1)

      by perrin (4270) on 2007.08.21 10:52 (#57124) Journal

      The main win for me is that I can accumulate conditions into queries (including composing result sets into one another) and let DBIC build the resulting SQL for me, instead of having to manually write template-ish SQL-generating logic for highly parametrisable queries.
      
      Any chance you could show an example? This is frequently cited as an interesting feature of DBIC, but there's not much in the docs about it. How is accumulating conditions and letting it build the SQL different from what the other SQL builders like SQL::Abstract or the one in Rose::DB::Object allow?
      
      I agree that SQL::Interpolate is a pretty interesting alternative when an ORM seems like a bad fit.

      Reply to This

      Parent

      • Re: (Score:1)

        by Aristotle (5147)

        It’s sort of a higher-order SQL.

        I can pass a ResultSet to someone else, and they can add constraints, joins, a group clause or such, as they like. This makes it much easier to decouple (and sometimes reuse) code. F.ex. I can build a ResultSet piecemeal along a chain of controllers in URI dispatch. I can even change some aspect of the query from within a template, eg. add a LIMIT clause to a passed-in ResultSet, without automatically having to tie the template to that particular query.

        Such a thing
        • Re: (Score:1)

          by perrin (4270)

          Thanks, that's the best explanation I've heard of it.
          
          I've mostly used the data structure approach. RDBO includes a query builder which is much more powerful than SQL::Abstract and is able to represent joins and complex conditions reasonably well. I've done work with that where the conditions are built up similar to what you describe and then passed to the query builder to be turned into SQL.