Rails - Feb 2007 - Prepared statements, bind variables, and bikesheds (was Re: Why should I use Ruby on Rails)

On 2/15/07, Wes Gamble
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

This has been tested, with the results posted to this list.  Check the
2nd half of 2006.

The tester used Postgres, and with a fairly crude setup reported
improvements of overall throughput from rails apps starting at 60
percent.  His alterations for testing  were mostly adaptable to other
SQL adapters, but not entirely portable.

He did a detailed timing breakdown of the ruby code versus the sql
engine, and determined that with prepared statements the bottleneck
changed   from the SQL to the ruby code.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---