検索条件が空を返す時にどうしてSQLを発行してんの？
User.where(id: [])
というコードを実行すると SELECT COUNT(*) FROM users WHERE 1=0という空を返却するSQLを発行している。必要なくね？というissue。
本issueに書かれた内容を要約すると、
SQLはselect ... where in ()というinの中身が空欄は不正なSQLになるから、エラーにならないように空結果を返すために1=0で検索しているけど、どうせ空配列を返すことはクエリする前から決まっているんだから内部でnoneメソッドを使えばいいのに。
まーでも、ここを最適化するよりもクエリをすることで実装がシンプルになるならこれでいいんじゃないの。
みたいな感じで、コミッターが登場することもなく答えのないままオープンになっている。
おしまい。
Remove unnecessary check.
issue 本文
railsアプリケーションは、デフォルトでapplictionオブジェクトをセットしている。 だから不要なチェックは削除する。
def root
- application && application.config.root
+ application.config.root
end
返信
Not everything that has done require "rails" is a (booted) Rails application.
require 'rails' を実行するとrailsアプリケーション、というのは全部じゃない。
感想
どういうケースでrailsアプリケーションじゃないのにrequire 'rails'をしているんだろう。 誤訳している？
updated_attributeメソッドで 属性が変更されなかったならtrueを返す
issue本文
If the attribute is not changed, then update_attribute does not run SQL query, this effectively means that no change was made to the attribute.
属性が変更されなかったらupdate_attributeメソッドはSQLクエリを実行せず、実際には項目に変更はなかったことを意味する。
This change was made in 0fcd4cf to avoid a SQL call.
この変更は SQLコールを防ぐ ofcd4cf で作られた。
But the change resulted into nil being returned when there was no change in the attribute value.
しかし、この変更の結果は、属性の値に変更がないときにnilを返すことになる
This commit corrects the behavior to return true if there is no change in attribute value. This is same as previous behavior of Rails 4.2 plus benefit of no additional SQL call. Fixes #26593.
属性の値に変更がない場合、trueを返す動作のコミットは正しい。
This is same as previous behavior of Rails 4.2 plus benefit of no additional SQL call.
この修正は、rails4.2以前と動作が同じである。
(of が多くて単語の切れ目とplus benefit がどこに掛かっているのかわからず)
@tenderlove We should backport as well, as this behavior was originally changed on 5.0.
バックポーツするべきだ。この振る舞いは5.0で変更された。
There was a conflict with persistence_test.rb so this commit could not be cherry-picked directly to 5-0-stable. I fixed the conflict and opened #26603 for back porting.
persistence_test.rb でコンフリクトがあって、5-0-stableに直接チェリーピックができなかった。 私は、コンフリクトの解消と バックポーツのために #26603 をオープンした。
DateTime#blank? のメソッドをempty?を使うように修正する
issue本文
I think DateTime#blank? should be use Object#blank? method.
DateTime#blank? は Object#blank? を使うべきだと思う。
WDYT?(Why do you thihk?)
どう思う？
返事
Inheritance is only left to non-whitelisted classes. The method is overridden in a bunch of them for performance reasons.
継承はノンホワイトリストクラスだけに任せている。(よくわからない....。？)
そのメソッドはパフォーマンス上のため上書きされている。
感想
Object#blank? は遅いって聞きますよね。
ActiveRecord exec_query fail for nonselect requests
本文
non select クエリーを exec_query#ActiveRecordで実行すると失敗する。
ActiveRecord::Base.connection.exec_query( 'update orders set id=1 where id=1' )
これのようなnon select クエリーを実行。
NoMethodError: undefined method `fields' for nil:NilClass
(正しいSQLとは独立して)例外になって失敗する。
(クエリは常に適用され、期待通りフィールドは常に更新された。)
これがバグじゃないなら、ActiveRecord::Resultインスタンスと同じいくつかのSQLを実行する方法
どうやって、選んだレコードと空レコードを判別しながら同じ結果(ActiveRecord::Result)のSQLを実行をするのか。
返信
Please use the mailing list or StackOverflow for questions/help, where a wider community will be able to help you. We reserve the issues tracker for issues only.
メーリングリストかスタックオーバーフローを質問・助けの場のために使って、広いコミュニティがあなたを助けることができるでしょう。
私達は、イシュートラッカーを課題のためだけに確保しています。
感想
2つの助動詞を入れられないためbe able toとwillがでてきて「進研ゼミでやったところだ！」ってなった。
Should AR where support `db_name.table_name.column_name` to key of hash?
issueの本文開始。
ActiveRecordのwhereは ハッシュのキー「 db_name.table_name.column_name」をサポートするべきです。
Now db_name.table_name.column_name is not supported as key of hash
今、db_name.table_name.column_nameはハッシューのキーとしてサポートしていない。
Rails 4.2.3 with mysql2
[1] pry(main)> User.where("id" => 1).to_sql => "SELECT
users.* FROMusersWHEREusers.id= 1"[2] pry(main)> User.where("users.id" => 1).to_sql => "SELECT
users.* FROMusersWHEREusers.id= 1"[3] pry(main)> User.where("db.users.id" => 1).to_sql => "SELECT
users.* FROMusersWHEREdb.users.id= 1"[3] is invalid SQL because
db.users.idRails 5.0.0 (07d6e1dc1fc78abaf46f9a73ded0b370ba489f6c) with mysql2
[1] pry(main)> User.where("id" => 1).to_sql => "SELECT
users.* FROMusersWHEREusers.id= 1"[2] pry(main)> User.where("users.id" => 1).to_sql => "SELECT
users.* FROMusersWHEREusers.id= 1"[3] pry(main)> User.where("db.users.id" => 1).to_sql => "SELECT
users.* FROMusersWHEREdb.users= 1"!!!! column name is lost!
Sure when we add database_name as AR.table_name these method create valid SQL
ActiveRecord.table_nameとしてdatabaseを追加すると正しいSQLを作ること確かめますね。
class User < ActiveRecord::Base self.table_name = "rails_spike_development.users" end
Rails 4.2.3 with mysql2
[1] pry(main)> User.where("id" => 1).to_sql => "SELECT
rails_spike_development.users.* FROMrails_spike_development.usersWHERErails_spike_development.users.id= 1"Rails 5.0.0 (07d6e1dc1fc78abaf46f9a73ded0b370ba489f6c) with mysql2
[1] pry(main)> User.where("id" => 1).to_sql => "SELECT
rails_spike_development.users.* FROMrails_spike_development.usersWHERErails_spike_development.users.id= 1"Both of them work correctly
But some gems use table_name as key
しかし、いくつかのgemはkeyとしてtable_nameを使う。
https://github.com/mbleigh/acts-as-taggable-on/blob/master/lib/acts_as_taggable_on/taggable/core.rb#L319 https://github.com/aasm/aasm/blob/master/lib/aasm/persistence/base.rb#L61
Should AR where support db_name.table_name.column_name to key of hash?
AR.whereは ハッシュのキーとしてdb_name.table_name.column_name をサポートするべきではありませんか？
レスの1つ目
@yui-knk did you find the commit that changed how this works? Maybe there's some insight there why this change happened in the first place.
あなたは、この働きに変更したコミットを見つけましたか？まー僕は発端はいくつか思い当たるけど。
レス2つ目
@senny I found out this commit change behavior.
私は変更の振る舞いのコミットを見つけた。 [...]
レス3つ目
We should definitely continue to make sure that this continues to generate invalid SQL and not silently do the wrong thing. That part should be easy to implement.
In terms of actually supporting this, I'm not a fan of allowing the db name in the string (or the dot notation in general for calls to where). One thing I am hoping to do is have where more specifically target the association, rather than the table, in order to gain more information about the model we're joining on. Once that lands, we could allow specifying database_name on the model class. However, I'd want to see a concrete use case for that, since if you statically know the database that the table lives on, I'm not sure why you'd want it on separate DBs to begin with.
The sharding use case is more complex (too much for me to get in depth on right now), but it is something I want to tackle (not so much to say "this is how you shard in Rails", but more to add the hooks required for you to do it without monkey patching). It's something I'll be working on in the near future.
私たちは、誤ったSQLを作成し、静かに誤りは続けずに間違いなく確認し続けるべき。 [...]
このdb_nameをハッシュのキーに入れたいということは了解してくれたみたいだけど、いつ取り込まれるんだろう。 目が離せません。
Should AR where support `db_name.table_name.column_name` to key of hash? · Issue #21326 · rails/rails · GitHub Remove @klass.table_name from scope conditions key by yui-knk · Pull Request #244 · aasm/aasm · GitHub
