On May 16, 5:49 am, "Michael A. Schoen" <[EMAIL PROTECTED]> wrote: > I'd have to disagree with you there. Rails actually performs very well > with Oracle. A change made a while back to default to "similar" > cursor_sharing resulted in much of the benefit of bind variables. > "performs badly" is definitely too strong.
I have no experience with Oracle, but according to some blogs, such as this one: http://uncommentedbytes.blogspot.com/2006/07/major-enterprise-ruby-on-rails-issues.html Rails performs badly because of the lack of use of prepared statements. Here is a quote from Greg Luck: "We have two production applications running on Ruby. And how is it. Well, despite being perhaps no more than 5% of the functionality of our applications, Ruby on Rails is the number one consumer of Oracle CPU and logical gets. Why? Rails does not support prepared statements, so Oracle has to reparse every time." And I forgot to mention this last time, but there's one more reason for using prepared statements/bounded variables: binary support in PostgreSQL. I have a Rails app which uses PostgreSQL, and its Person.password_password column was of the type bytea. It contains a raw hash of the user's password. When a user logs in, the app performed the following query: Person.find_by_username_and_password_hash(username, calculate_hash(password)) This will send a query to PostgreSQL, and this query will contain a binary string. However, in PostgreSQL, binary strings must be escaped with escape_bytea() - the regular string escaping function will not do. Because the binary string isn't escaped properly, the whole database connection breaks (it throws an exception, something about "character not allowed in Unicode mode" or something). One may wonder why the binary string isn't escaped correctly. The reason is this: 1. It seems impossible in Ruby to determine whether a String contains binary data without scanning through the entire String (expensive), so the current PostgreSQL adapter assumes that strings are text strings, and escapes them as text strings, unless it knows that this string belongs to a binary column. 2. During ActiveRecord::Base.save, ActiveRecord will now which attributes belong to which columns, so saving records that contain binary data is no problem. The string escaper will have knowledge about which argument belongs to which column. 3. However, things go wrong during ActiveRecord::Base.find. In there, it is impossible to find out which arguments belong to which table columns. By using prepared statements/bounded variables, we can eliminate this entire problem. Strings will not be escaped, but be directly bounded to a prepared statements. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
