Hard work by INTERNET

ベンチャーで働くひとりぼっちWEB開発者が頑張るブログ

Remove unnecessary check.

github.com

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を返す

github.com

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?を使うように修正する

github.com

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

github.com

本文

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がでてきて「進研ゼミでやったところだ!」ってなった。

restartタスクの中でrailsコマンドを使え

github.com

Be consistent in testing outputs from railties test and use /bin/rails by vipulnsward · Pull Request #23212 · rails/rails · GitHub に関連する。

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.* FROM users WHERE users.id = 1"

[2] pry(main)> User.where("users.id" => 1).to_sql => "SELECT users.* FROM users WHERE users.id = 1"

[3] pry(main)> User.where("db.users.id" => 1).to_sql => "SELECT users.* FROM users WHERE db.users.id = 1"

[3] is invalid SQL because db.users.id

Rails 5.0.0 (07d6e1dc1fc78abaf46f9a73ded0b370ba489f6c) with mysql2

[1] pry(main)> User.where("id" => 1).to_sql => "SELECT users.* FROM users WHERE users.id = 1"

[2] pry(main)> User.where("users.id" => 1).to_sql => "SELECT users.* FROM users WHERE users.id = 1"

[3] pry(main)> User.where("db.users.id" => 1).to_sql => "SELECT users.* FROM users WHERE db.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.* FROM rails_spike_development.users WHERE rails_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.* FROM rails_spike_development.users WHERE rails_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

DNSの理解を少し深めた

/proc を探検する - いますぐ実践! Linuxシステム管理 / Vol.023

名前解決の理解がかなり曖昧だった。
NSサーバを適当に登録して、aレコードやcnameレコードを適当に投稿してWEBサーバのバーチャルホストを設定するだけで大抵動くので曖昧のままでご飯を食べれてた。

今回、ブラウザが再帰的に権威サーバへ再帰的に問合せしている手順をdigコマンドを使って再現した。 だがまだ理解が微妙だ。

今回はgoogle.comの名前解決をしてみた。

com を知っているnsサーバを問い合わせる

$ dig com ns
;; ANSWER SECTION:
com.                    11257   IN      NS      m.gtld-servers.net.
com.                    11257   IN      NS      j.gtld-servers.net.
com.                    11257   IN      NS      e.gtld-servers.net.
com.                    11257   IN      NS      c.gtld-servers.net.
com.                    11257   IN      NS      l.gtld-servers.net.
com.                    11257   IN      NS      k.gtld-servers.net.
com.                    11257   IN      NS      g.gtld-servers.net.
com.                    11257   IN      NS      i.gtld-servers.net.
com.                    11257   IN      NS      a.gtld-servers.net.
com.                    11257   IN      NS      h.gtld-servers.net.
com.                    11257   IN      NS      d.gtld-servers.net.
com.                    11257   IN      NS      f.gtld-servers.net.
com.                    11257   IN      NS      b.gtld-servers.net.

答えがたくさん帰ってきた。com を知っているサーバは*.gtld-servers.netだ。

次は *.gtld-servers.netのnsに対して、google.com のnsを問い合わせる。

google.com の ns サーバを問い合わせる

$ dig @a.gtld-servers.net google.com ns
;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

google.com を登録しているnsサーバは ns2.google.com あたりということがわかった。 次はaレコードをns2.google.comに問い合わせる。

$ dig @ns2.google.com google.com a
;; ANSWER SECTION:
google.com.             300     IN      A       173.194.117.199
google.com.             300     IN      A       173.194.117.194
google.com.             300     IN      A       173.194.117.192
google.com.             300     IN      A       173.194.117.197
google.com.             300     IN      A       173.194.117.201
google.com.             300     IN      A       173.194.117.200
google.com.             300     IN      A       173.194.117.193
google.com.             300     IN      A       173.194.117.206
google.com.             300     IN      A       173.194.117.196
google.com.             300     IN      A       173.194.117.198
google.com.             300     IN      A       173.194.117.195

google.com を手で問い合わせた。

権威サーバというのは、com や google.com のnsを知っているサーバのことを指すらしい。 ns2.google.com は 権威サーバというのかな。

ゾーンファイルを持っているのは、ns2.google.com だと思う。

うーーーーーん。なんか微妙に理解ができていない。 nsレコードとはなんなんだ....。