DBIx::Class - Related Tables

[Andy Wardley]

Aaron Trevena wrote:
> 99.9% of the time that is either a rare edge case, or a case of not being
> totally up to speed.

Depends on the ORM, though.  I'm not knocking DBIC in particular (which is
certainly one of the best, IMHO), but there are a lot of other ORMs out
there in various different languages, and many fall short of what DBIC can do.

> It's a case of knowing your tools,

Absolutely.  Once you know a particular tool, you're laughing.  But part of
the problem is that there are so many different tools (in the general case)
and they're all similar, but different.  I think I used a total of 4 different
ones last week, 2 in Perl (DBIC and my own), one in Python (SQLAlchemy) and
one in PHP (doctrine - not through choice, I hasten to add, but I had to
recommend something to a PHP shop).  Although many of the basic concepts are
portable, figuring out the specific detail can be painful, especially if the
documentation isn't up to scratch.

Of course, that's a rather exceptional situation.  But it does illustrate
the point that SQL by itself is a very portable skill because it is (for the
most part) standardised.  Investing time in learning SQL will never be wasted.
Unfortunately we don't have anything approaching even an ad-hoc standard for
ORMs, so it's often back to square one every time you pick up a new one.

It's particularly difficult with those that require you to learn a whole bunch
of new concepts (or adjust your previous idea of similar concepts to a new
mental model) before you can get as far as fetching a record from a table.  I
think most ORMs are guilty of this, although it probably goes with the
territory to some extent.  You can spend hours, days or even weeks getting up
to speed with an ORM only to find out that it falls short of what you actually
want.

Again, this is a comment on ORMs in general, rather than DBIC.

> perl ORMs allow you to fall back to using handcoded SQL, or to
> over-ride default behaviour,

Yes, I think that's definitely the right approach. If you already know SQL
then an ORM should make it easy for you to use it, or to plug in your
favourite SQL generation tool (e.g. SQL::Abstract) to create it for you.
But I wonder if that isn't acknowledging that the best ORMs are those that
make it easy to break the abstraction and get down'n'dirty with raw SQL.

I stand by my phrasebook analogy.  An ORM provides you with standard
"phrases" (i.e. queries), written by experts in the field (or generated by
code that was written by experts), that you can use to get the job done
without having to really understand the underlying language at all.  That's
not to say that you can't or won't pick up the language as you go along, or
that it won't be useful in the long run.  But it is the tool by which a lay
person can translate their intent (coffee, please / insert this record) to a
native format (cafe s'il vous plait / INSERT INTO ...) that can be understood
and acted upon.

Well, that's how I see it anyway.  It wasn't meant to be belittling in the
comical "My wife has been misplaced by my bagpipes" kind of bad translation
sense.

A