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 Sat, 05 Jul 2008 18:40:56 +0000 http://wordpress.org/?v=2.3.3 By: Mike M http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-9242 Mike M Wed, 25 Jun 2008 17:51:28 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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-7458 Hongli Sun, 09 Dec 2007 00:03:15 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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-7457 Ned Wolpert Sat, 08 Dec 2007 23:29:47 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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-7456 Hongli Sat, 08 Dec 2007 19:02:48 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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-7455 Ned Wolpert Sat, 08 Dec 2007 18:26:51 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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-6557 Matadon Mon, 23 Jul 2007 21:51:02 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#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!

]]> By: Charles Oliver Nutter http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6507 Charles Oliver Nutter Fri, 01 Jun 2007 18:28:27 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6507 Hey were were talking on #jruby today about how to support prepared statements, and wham, someone pointed us to this blog post. This is exactly what we had in mind--feeding fragments to a statement builder, composing the actual statements later, possibly using a prepared statement (JIT style I'd guess, since we don't want to compile every random query that comes through). This is great work...and there's a new wrinkle I'd like to toss in. It would be trivial for us to use prepared statements in the backend code of the ActiveRecord JDBC adapter, since the API for such is exactly the same all the time...and almost identical to the API for normal statements. If you've got something working for MySQL, it may be possible to get it running for all databases in AR-JDBC in a very short time. I think that would be an excellent way to try this out across the board and see how well it works. If you get a chance, please contact me or join the JRuby or JRuby-extras (rubyforge) mailing lists...we could probably come up with something really cool. Hey were were talking on #jruby today about how to support prepared statements, and wham, someone pointed us to this blog post. This is exactly what we had in mind–feeding fragments to a statement builder, composing the actual statements later, possibly using a prepared statement (JIT style I’d guess, since we don’t want to compile every random query that comes through). This is great work…and there’s a new wrinkle I’d like to toss in.

It would be trivial for us to use prepared statements in the backend code of the ActiveRecord JDBC adapter, since the API for such is exactly the same all the time…and almost identical to the API for normal statements. If you’ve got something working for MySQL, it may be possible to get it running for all databases in AR-JDBC in a very short time. I think that would be an excellent way to try this out across the board and see how well it works.

If you get a chance, please contact me or join the JRuby or JRuby-extras (rubyforge) mailing lists…we could probably come up with something really cool.

]]> By: Hongli http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6500 Hongli Thu, 24 May 2007 07:59:56 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6500 doug livesey: I would like to, but I don't have access to anything but MySQL and PostgreSQL (and perhaps SQLite). doug livesey: I would like to, but I don’t have access to anything but MySQL and PostgreSQL (and perhaps SQLite).

]]> By: doug livesey http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6499 doug livesey Thu, 24 May 2007 07:30:19 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6499 Hi -- is there any plan to support the entire suite of DBs supported by Rails? I was a very bad man in an earlier life, so I have to work with SQL Server, and have had to deal with all sorts of little peculiarities -- particularly in migrations. Anyway, this looks fantastic! Cheers, Doug. Hi — is there any plan to support the entire suite of DBs supported by Rails?
I was a very bad man in an earlier life, so I have to work with SQL Server, and have had to deal with all sorts of little peculiarities — particularly in migrations.
Anyway, this looks fantastic!
Cheers,
Doug.

]]> By: Daniel Berger http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6498 Daniel Berger Tue, 22 May 2007 16:36:16 +0000 http://izumi.plan99.net/blog/index.php/2007/05/14/unsupport-for-prepared-statements-in-ruby-on-rails/#comment-6498 Here's a great article from Oracle you'll want to look at that discusses bind parameters and Rails: http://www.oracle.com/technology/pub/articles/mearelli-optimizing-oracle-rails.html As for MySQL, Eric Hodel tells me that the MySQL server clears the query cache as soon as you run an INSERT or DELETE, which makes it pretty useless IMHO. Here’s a great article from Oracle you’ll want to look at that discusses bind parameters and Rails:

http://www.oracle.com/technology/pub/articles/mearelli-optimizing-oracle-rails.html

As for MySQL, Eric Hodel tells me that the MySQL server clears the query cache as soon as you run an INSERT or DELETE, which makes it pretty useless IMHO.

]]>