I agree with some of your points. However, I’d like to add that it is because I am “actually using Rails” (and have been for a year) that I find these features to be important. I’ve been using prepared DB
statements to optimize DB access for over 10 years on innumerable platforms/deployment scenarios and I don’t have access to them in AR - feels like I’m taking a step back.
I apologize for the generalization. I don’t mean to single you out. Rather, I challenge the community to trash the bikeshed and conscientiously un-suck the bits of Rails that suck the life out of you.
If the prospect of increased CPU consumption due to unprepared queries rubs you deep, hard, and oh so wrong, don’t stop marking your hurt at some spilt words in a mailing list thread – write the well-tested code to scream it out to the world!
Your apps-- all of ours-- will purr in thanks, memorializing your genius forever
I’d love to work on this when I get some time. As it stands, I’ve submitted two (admittedly small) patches on ActiveRecord::Base in the last 6 months. Maybe I will give it a try. Thanks for the encouragement.
Cheers!
It’s probably easier than it seems: bind variables are emulated and could be pushed down to the adapter. http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/base.rb#L1404 The adapter could prepare the statement in Adapter#sanitize_sql, cache it, and return a SqlStatement < String holding both the query string and its bound vars. Adapter#execute can pass bound vars directly to the db when given a SqlStatement.
Thorough test coverage and broad database support are likely the greater challenge.
Best, jeremy