in reply to Re: Switch from DBI to DBIx::Class: thoughts?
in thread Switch from DBI to DBIx::Class: thoughts?

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.

  • Comment on Re^2: Switch from DBI to DBIx::Class: thoughts?

Replies are listed 'Best First'.
Re^3: Switch from DBI to DBIx::Class: thoughts?
by frew (Acolyte) on Mar 16, 2009 at 22:19 UTC
    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