0

非常に大きな Rails 2.3 アプリケーションを ruby​​ 1.8 から 1.9 に移行しています。その過程で、古いruby-mysqlgem からmysql2.

これは、すべてのActiveRecord::BaseORM のようなクエリ (@users = User.find(:all, :conditions => {...})など) で正常に機能しましたが、アプリケーションは、パフォーマンス関連の問題について、DB への直接クエリに大きく依存しています。次のようなものをよく見かけます。

ActiveRecord::Base.connection.execute(optimized_sql).each_hash do |row|
  # do some stuff with row
end

また

# for specific connections (different servers, etc)
client = Mysql.real_connect(host, username, password, schema)
client.query(tweaked_sql).each_hash do |row|
  # do some stuff with row
end

また

# for batch inserts
client.autocommit(false)
insert_list.each { |insert| client.query(insert) }
client.commit

このクエリは、主にそのために記述された指定されたクラス ファイルで行われることに注意してください。したがって、コントローラーやモデルなどではなく、主にapp_root/lib/. また、古い宝石で使用したものと同等の機能を多く見つけることができないようです。良い例は#autocommitlike メソッドです (複数の INSERT などのバッチ クエリを有効にするため)。

mysql2すべてのActiveRecordものとruby-mysqlデータベースへのクライアントの直接接続のために、両方のgemを使用して移行をスムーズにしたいと思います。ただし、アプリの Gemfile に両方を含めると、Rails はデフォルトでどちらか一方に設定されているようです。アプリの読み込み時に Gemfile を含めるruby-mysqlだけで自動的に要求しないように構成する方法はありますか?

require 'mysql'両方が存在することを確認し、古い宝石を厳密に使用したいファイルでのみ使用するにはどうすればよいですか? 私が取るべき他のアプローチはありますか？アプリ全体を一気に変換するのはかなり大きなリスクであり、私のチームが古いコードを Mysql から Mysql2 に適応させて移行する時間を確保したいと考えています。

ありがとう。

4

1 に答える 1