A .NET ORM? Please read the article before posting. Thanks.

“…A secondary issue with Fixtures is that they go directly from YAML text files to SQL INSERT statements, bypassing the ActiveRecord Model classes….this model-skipping fixture loading implementation means that any code in your model object (validations, before_save filters, etc.) will not be executed when loading fixtures”

In my case, there are no foreign key dependencies, but I’m using a legacy database that doesn’t include autoincrement or support sequences, so I need to generate primary key id’s in the before_create callback. Since fixtures bypass the model, can’t use them in the tests.

Very informative post. Thanks.

Perhaps it is no longer even possible to speak of any “groupthink” pertaining to the Rails-community as a whole, on any topic whatsoever. That is, unless one refers to the _core_ of the Rails community, in which case there definately are no “SQL is dirty” sentiments.

Maybe it’s a vocal minority who are anti-RDMBS and/or anti-SQL – it’s hard to tell. I can change the wording to something other than “groupthink” if it’ll help.

The issue that matters to me is the API and how it could be better. If there are people who would reject patches to make using SQL with Rails easier due to an ideological disdain of SQL, that needs to be addressed in order to make the API better. if not, well, joy and celebration.

But Isn’t SQL Dirty?

Ever since developers first wrapped relational databases with an object-oriented layer, they’ve debated the question of how deep to run the abstraction. Some object-relational mappers seek to eliminate the use of SQL entirely, hoping for some object-oriented purity by forcing all queries through an OO layer.

ActiveRecord does not. It was built on the notion that SQL is neither dirty nor bod, just verbose in the trivial cases. The focus on removing the need to deal with the verbosity in those trivial cases (writing a 10-attribute insert by hand will leave any programmer tired) but keeping the expressiveness around for the hard queries — the type SQL was created to deal with elegantly.

Therefore, you shouldn’t feel guilty when you use find_by_sql to handle either performance bottlenecks or hard queries. Start out using the object-oriented interface for productivity and pleasure, and then dip beneath the surface for a close-to-the-metal experience when you need to do so.

I kid you not.