Comments on: (Un)Support for prepared statements in Ruby on Rails http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/ Ecchi nanowa ikenai to omoimasu Fri, 09 Apr 2010 11:42:43 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Sam Homer http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-10047 Sam Homer Sun, 07 Mar 2010 14:01:33 +0000 http://izumi.plan99.net/blog/?p=35#comment-10047 The DB2 database adapter for Rails 3 supports prepared statements: http://www.ibm.com/developerworks/data/library/techarticle/dm-1001db2rubyonrailsapps/ Now if only somebody could add this feature to the PostgreSQL adapter as well. To me the main reason to use prepared statements is not performance but security. In addition, the very nature of a rails app makes it a prime candidate for prepared statements: Rails basically fills templates with live data, and every template invocation calls the same queries, only with different parameters. The DB2 database adapter for Rails 3 supports prepared statements:
http://www.ibm.com/developerworks/data/library/techarticle/dm-1001db2rubyonrailsapps/

Now if only somebody could add this feature to the PostgreSQL adapter as well. To me the main reason to use prepared statements is not performance but security. In addition, the very nature of a rails app makes it a prime candidate for prepared statements: Rails basically fills templates with live data, and every template invocation calls the same queries, only with different parameters.

]]> By: Barath http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-9915 Barath Wed, 29 Apr 2009 12:52:29 +0000 http://izumi.plan99.net/blog/?p=35#comment-9915 Hi, I am curious about your final comment. Could you make clear the reason why you think there is not enough performance advantages. Did you try to 'benchmark' your changes with a database/driver that caches prepared statements. . Barath Hi,

I am curious about your final comment. Could you make clear the reason why you think there is not enough performance advantages. Did you try to ‘benchmark’ your changes with a database/driver that caches prepared statements.

.

Barath

]]> By: Hongli http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-9652 Hongli Mon, 01 Dec 2008 20:23:49 +0000 http://izumi.plan99.net/blog/?p=35#comment-9652 I've given up on this patch. There are not enough advantages to make it worthwhile. I’ve given up on this patch. There are not enough advantages to make it worthwhile.

]]> By: Wes Gamble http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-9651 Wes Gamble Mon, 01 Dec 2008 20:06:27 +0000 http://izumi.plan99.net/blog/?p=35#comment-9651 Any more news on this patch? Still very interested... Any more news on this patch? Still very interested…

]]> By: Mike M http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-9242 Mike M Wed, 25 Jun 2008 17:51:28 +0000 http://izumi.plan99.net/blog/?p=35#comment-9242 Hi, What is the status of the patch? Mike Hi,

What is the status of the patch?

Mike

]]> By: Hongli http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-7458 Hongli Sun, 09 Dec 2007 00:03:15 +0000 http://izumi.plan99.net/blog/?p=35#comment-7458 Yes it's possible. So far I've resisted the idea though: my patch changes a lot of ActiveRecord internals. Plugin-izing all this will mean overwriting a lot of private methods. If the Rails team changes even one line of code to ActiveRecord then it's likely that the plugin will break. You can see exactly what has changed by comparing http://public.railsplugins.net/repos/prepared-statements/trunk/ with http://public.railsplugins.net/repos/prepared-statements/vendor/rails-r6737/ The code will probably have to be updated in order to be Rails 2.0 compatible. Yes it’s possible. So far I’ve resisted the idea though: my patch changes a lot of ActiveRecord internals. Plugin-izing all this will mean overwriting a lot of private methods. If the Rails team changes even one line of code to ActiveRecord then it’s likely that the plugin will break.

You can see exactly what has changed by comparing http://public.railsplugins.net/repos/prepared-statements/trunk/ with http://public.railsplugins.net/repos/prepared-statements/vendor/rails-r6737/
The code will probably have to be updated in order to be Rails 2.0 compatible.

]]> By: Ned Wolpert http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-7457 Ned Wolpert Sat, 08 Dec 2007 23:29:47 +0000 http://izumi.plan99.net/blog/?p=35#comment-7457 Do you think its possible to transform the patch into a plugin? The repo has tons of stuff in it... I assume only part of the activerecord side needs to occur. I'm willing to try and create a plugin against Rails 2.0 codebase... though I could see keeping it up to date with activerecord changes may be... interesting. Do you think its possible to transform the patch into a plugin? The repo has tons of stuff in it… I assume only part of the activerecord side needs to occur. I’m willing to try and create a plugin against Rails 2.0 codebase… though I could see keeping it up to date with activerecord changes may be… interesting.

]]> By: Hongli http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-7456 Hongli Sat, 08 Dec 2007 19:02:48 +0000 http://izumi.plan99.net/blog/?p=35#comment-7456 I haven't worked on this for a while now. But the source code is available on the following SVN repostory: http://public.railsplugins.net/repos/prepared-statements/trunk/ This code is based on Rails revision 6737 (about 6 months ago). I haven’t worked on this for a while now. But the source code is available on the following SVN repostory: http://public.railsplugins.net/repos/prepared-statements/trunk/
This code is based on Rails revision 6737 (about 6 months ago).

]]> By: Ned Wolpert http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-7455 Ned Wolpert Sat, 08 Dec 2007 18:26:51 +0000 http://izumi.plan99.net/blog/?p=35#comment-7455 What is the latest status of prepared statements and ActiveRecord? Is it still in patch form? Could the patch be turned into a plugin? Need any help? What is the latest status of prepared statements and ActiveRecord? Is it still in patch form? Could the patch be turned into a plugin?

Need any help?

]]> By: Matadon http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/comment-page-1/#comment-6557 Matadon Mon, 23 Jul 2007 21:51:02 +0000 http://izumi.plan99.net/blog/?p=35#comment-6557 This is exactly the sort of thing I had in mind, although more with bound variables than prepared statements. I use PostgreSQL as a backend, and Rails' performance, especially with large JOINs and big chunks of data, leaves quite a bit to be desired. If you want a hand in testing and/or coding for Postgres, let me know! This is exactly the sort of thing I had in mind, although more with bound variables than prepared statements. I use PostgreSQL as a backend, and Rails’ performance, especially with large JOINs and big chunks of data, leaves quite a bit to be desired. If you want a hand in testing and/or coding for Postgres, let me know!

]]>