To me, the most painful part of working with Ruby on Rails has been the immaturity of the supporting documentation, specifically as regards ActiveRecord. I know there are boatloads of Ruby on Rails books on the way, and to me, the one that’s most needed is an in depth explanation of how ActiveRecord works and what you can do with it. I’m also beginning to wonder if ActiveRecord isn’t perhaps a bit thinner than I originally gave it credit for. It works brilliantly for all of the simple stuff I was doing initially, but now that I’m moving to the next level of complexity, I find myself a bit lost in the wilderness.
First, let me say that ActiveRecord supports a mechanism called “find by SQL,” which basically lets you create join clauses and where clauses in any way that you choose. What I’m trying to figure out is whether I have to go that route for a large class of queries that would seem to be common to many types of applications. Let me give you an example. You have two tables in the database called questions and categories. (I call them that because that’s really what they’re named in my application. They have a many to many relationship with one another, so I have another table called categories_questions. Let’s say that I want to create a page that lists all of the uncategorized questions. I could write a SQL statement like this:
select * from questions where not exists (select question_id from categories_questions where question_id = question.id)
If I preferred, i could do the same thing with a left outer join, like this:
select q.* from questions q left outer join categories_questions cq on q.id = cq.question_id where cq.category_id is null
It strikes me that I should be able to do both of these things within ActiveRecord without reproducing most of those queries using find_by_sql. You wouldn’t know it though from any of the online resources I’ve looked at, or the Rails book from the Pragmatic Programmers, or any of the open source Rails applications that I’ve browsed.
I had forgotten how much fun being an early adopter can be.
April 28, 2006 at 12:29 pm
The interesting thing is there was a time not to long ago when the Rails documentation was phenomenal! Really one of the compelling reasons to use the framework, but I found the ActiveRecord implementation immature.
In the last 9-12 months the complexity of the Rails framework has exploded, the documentation has failed to keep up, and the collective knowledge around the framework has fractured with a variety of experts, and documents frozen in amber at various levels of corretness. Growth is hard.
April 28, 2006 at 12:34 pm
Oh (and I’m a neolithic Rails user, so ignore me) but I reach for find_by_sql alot. Because sometimes taking the time to roll a hand written SQL statement will knock the number of queries and time to complete down by 3-4 orders of magnitude.
I also write a lot of custom acts_as_… for SQL patterns I use over and over.
April 28, 2006 at 2:35 pm
did you try using :through associations ? assuming a none_category to provide a nil id
http://wiki.rubyonrails.com/rails/pages/ThroughAssociations
April 28, 2006 at 5:17 pm
Rails has always been a collection of solutions to problems encountered by the contributors. I’ve never needed the query you describe above, so I have never abstracted it. Apparently nobody else have either. Or they have, but didn’t share their abstraction.
Thus, this is a great opportunity for you to share your find if you believe it falls under what “most people need most of the time”.
Depending on the number of questions you have, you can also always just Ruby bruteforce it: questions.select { |q| q.categories.empty? }. That won’t work with hundreds of questions, but I don’t know your domain, so perhaps its just fine.
Regarding the documentation, we’re always willing to accept patches. If you stumble over a part of the documentation that seems to be lacking, please do help to make it better. It’s actually really easy, we have simple instructions on the dev.rubyonrails.org site.
Looking forward to your contributions.
Oh, and find_by_sql is not bad. Don’t feel dirty for using it. It’s only dirty if you keep seeing the same exact SQL statements over and over again and you don’t abstract it. But you’re of course a thoughtful DRY-seeking developer, so I’m sure you will 😉