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