白い烏

ActiveRecordの関連で、保存の伝播関係がわからなくなったので整理

r2o — 2013-10-06T14:06:19+09:00

久しぶりにRailsに戻ってきたら、あまりにもバージョンが違いすぎてて、なんか浦島太郎気分。

で、ActiveRecordで関連を持ったときに、保存の伝播の仕方が混乱してきたので整理してみた。

結論を先に言うと、
親のメソッドで代入したときはsaveの伝播はなされるが、子のメソッドから代入したときはsaveの伝播はなされない。
つまり、has_many, has_oneとbelongs_toは独立して動作する、ということ。

ふむ。シンプル。

試しにプロジェクト作ってみて、動かして確認。

HogeParent
has_many :hoge_children

has_one :hoge_has_one



HogeChildren

belongs_to :hoge_parent



HogeHasOne

belongs_to :hoge_parent

親は未保存

hoge_parent = HogeParent.new
hoge_parent.name = "post_save hoge"
hoge_parent.new_record? = true
hoge_child = HogeChild.new
hoge_child.name = "post_save child"
hoge_child.new_record? = true
hoge_has_one = HogeHasOne.new
hoge_has_one.name = "post_save has_one"
hoge_has_one.new_record? -> true

親が未保存の時、親のメソッドで代入する

hoge_parent.hoge_children << hoge_child
hoge_child.hoge_parent_id -> nil
hoge_child.new_record? -> true
hoge_parent.hoge_has_one = hoge_has_one
hoge_has_one.hoge_parent_id -> nil
hoge_has_one.new_record? -> true

当然のことながら、この時点では何も起こらない

親が未保存の時に親のメソッドで代入したもので、親を保存したとき

hoge_parent.save
hoge_parent.new_record? -> false
hoge_child.new_record? -> false
hoge_child.hoge_parent_id -> 10
hoge_has_one.new_record? -> false
hoge_has_one.hoge_parent_id -> 10

親の保存が伝播して、子のhoge_prent_idに自動的にIDが保存され、子も一緒にsaveされる

親を先に保存する

saved_hoge_parent = HogeParent.new
saved_hoge_parent.name = "pre_save hoge"
saved_hoge_parent.save -> true
saved_hoge_parent.new_record? -> false
saved_hoge_parent.id -> 11 
saved_hoge_parent.new_record? = false
saved_hoge_child = HogeChild.new
saved_hoge_child.name = "pre_save child"
saved_hoge_child.new_record? = true
saved_hoge_has_one = HogeHasOne.new
saved_hoge_has_one.name = "pre_save has_one"
saved_hoge_has_one.new_record? -> true

親を先に保存して、親のメソッドで代入

saved_hoge_parent.hoge_children << saved_hoge_child
saved_hoge_child.new_record? -> false
saved_hoge_child.hoge_parent_id -> 11
saved_hoge_parent.hoge_has_one = saved_hoge_has_one
saved_hoge_has_one.new_record? -> false
saved_hoge_has_one.hoge_parent_id -> 11

代入が成功した時点で、自動的にhoge_parent_idが格納されてsaveが呼ばれる

親が未保存

post_save_hoge_parent = HogeParent.new
post_save_hoge_parent.name = "post_save hoge"
post_save_hoge_parent.new_record? = true
post_save_hoge_child = HogeChild.new
post_save_hoge_child.name = "post_save child"
post_save_hoge_child.new_record? = true
post_save_hoge_has_one = HogeHasOne.new
post_save_hoge_has_one.name = "post_save has_one"
post_save_hoge_has_one.new_record? -> true

親が未保存で、子のメソッドで代入

post_save_hoge_child.hoge_parent = post_save_hoge_parent
post_save_hoge_child.new_record? -> true
post_save_hoge_child.hoge_parent_id -> nil
post_save_hoge_has_one.hoge_paent = post_save_hoge_parent
post_save_hoge_has_one.new_record? -> true
post_save_hoge_has_one.hoge_parent_id -> nil

親が未保存で、子のメソッドで代入したもので、親を保存したとき

post_save_hoge_parent.save -> true
post_save_hoge_parent.new_record? -> false
post_save_hoge_parent.id -> 12
post_save_hoge_child.new_record? -> true
post_save_hoge_child.hoge_parent_id -> nil
post_save_hoge_has_one.new_record? -> true
post_save_hoge_has_one.hoge_parent_id -> nil

親のsaveは伝播しない。子のhoge_parent_idも更新されない

親を先に保存

pre_saved_hoge_parent = HogeParent.new
pre_saved_hoge_parent.name = "pre_save hoge"
pre_saved_hoge_parent.save -> true
pre_saved_hoge_parent.new_record? -> false
pre_saved_hoge_parent.id -> 13 
pre_saved_hoge_parent.new_record? = false
pre_saved_hoge_child = HogeChild.new
pre_saved_hoge_child.name = "pre_save child"
pre_saved_hoge_child.new_record? = true
pre_saved_hoge_has_one = HogeHasOne.new
pre_saved_hoge_has_one.name = "pre_save has_one"
pre_saved_hoge_has_one.new_record? -> true

親を先に保存して、子のメソッドで代入

pre_saved_hoge_child.hoge_parent = pre_saved_hoge_parent
pre_saved_hoge_child.new_record? -> true
pre_saved_hoge_child.hoge_parent_id -> 13
pre_saved_hoge_has_one.hoge_parent = pre_saved_hoge_parent
pre_saved_hoge_has_one.new_record? -> true
pre_saved_hoge_has_one.hoge_parent_id -> 13

自動的に保存はされない。当たり前だが、すでに親のIDはわかっているので、hoge_parent_idは格納されている

XCodeのGitがうまくコミットできなかった件について

r2o — 2012-07-31T20:04:25+09:00

最近はiOSアプリばっかりつくっているので、XCodeにはお世話になっているわけですが、
当然ソース管理は同梱されているGitを使うわけです。

が、このGit、コミットは出来てもロールバックは出来ない、という何とも片手落ちな仕様となっており、
先日もあちゃーということがあってロールバックする為に、Google先生の助けを借りて、
コマンド叩いてロールバックしたりした次第。

で、はまったのが全角文字のファイル問題。

データ提供元から送られてきたアイコン画像を使用したところ、
突然コミットが出来なくなると言う状態が発生。

コミットするのにファイルがねえ、という旨のメッセージが出て、コミットが進まない。

error: pathspec '問題のアイコンファイル名' did not match any file(s)

というメッセージ。
ファイル名の一部がエスケープされていたので、ファイル名に全角がある為というのが分かった。

そこで、ファイル名(全角アルファベットが混じってたので、
(Xcodeのフォントになれてなくて、全角と半角、見比べてみるまで判別ができない))
ファイル名を半角に変更。

コミットするも同じメッセージが。
で、コマンドから　git rm　とか、いろいろやってみるも変化なし。

で、更に調べると、
とにかくGitの設定にマルチバイト読込の設定をしてやる必要があると言うことが分かった。

コマンドから、

git config --global gui.encoding utf-8

これで一件落着

date_selectの初期値設定でのハマり

r2o — 2010-10-18T01:41:27+09:00

日付の選択は日時の選択で便利なビューヘルパのdate_selectとdatetime_select。

こんかいのハマりは初期値の設定。

特定の日付を指定するのは、第一引数にTimeデータを格納してやればいいのは知ってる。

しかし、

:prompt=>true
とか、
:include_blank=>true
とかやって、
初期値をこのプロンプトもしくはブランクに指定する方法がわからなくて探した…

ドキュメントに書いてないやん。

ググって見ても、初期値に特定の日付を指定する方法ばかり出てくる。
そんなんドキュメントにしっかり書いてあるやろが！!

と半ばキレながら試した見た。

そう、答えは簡単。
第一引数にnilを入れると。

でたよ～Rails得意の怪しかったら試してみろパターン。

というわけで、
解決しました…orz

rails2.3のタイムロケールでハマる

r2o — 2010-02-16T19:05:41+09:00

スケジューラー実装中のこと。

いろんな時間の予定を作って、特定の日時で切って取得するテストをする。
が、いざやってみると思ってない時間の予定が取得されてる。

おかしい。
とりあえずトレースしてみると、変な時間が入ってる。

午前0時に設定したはずが、午後3時とか。

境界テストのためにかなりの種類の予定を作っているので、
打ち間違いとか、間違って上書きとかの可能性を探って見るもだめ。

しょうがないので、
代入する時間、代入された時間をトレースしてみる。
代入するまではきちんとしてるのに、
オブジェクトに代入したとたんにおかしなことになってる。

あっれ～とか思いつつ、よくよく見てみると、
オブジェクトに代入した時間がJST +00:00になってるよ。

あ～、タイムロケールか～というわけで、タイムロケール設定をしていなかったんですねえ・・・

/config/environment.rbで、

config.time_zone = 'UTC'
を
config.time_zone = 'Tokyo'
に変更。

ちゃんとJST +09:00になりました。

ちゃんちゃん。

#　ってﾀﾞﾒﾀﾞｺﾚ
どうもDBへの入出力でおかしくなってるみたいで一度保存するとおかしな状態のままになってる。
しょうがないので、国内限定、ってことで
# config.time_zone = 'Tokyo'
とコメントアウトして対応。

orz

ActiveRecord::Base.destoryをオーバーライドする

r2o — 2010-02-06T11:28:42+09:00

テーブル関連、has_oneとかhas_manyとかの関連を持っているとき、
ついついActiveRecord::Base.destroyとかをオーバーライドしたくなるときがある。

例:

class Parent < AciveRecord::Base
has_many :chidren, :dependent=>:destroy

# 属性:deleted, :boolean, :default=>false

end

class Child < AciveRecord::Base
belongs_to :parent

# 属性:deleted, :boolean, :default=>false

end

親も子も関連する全員が@deletedがtrueになったときだけ全削除の実行に入る、
という必要があったとする。

親の方は簡単で、エイリアスを作ってオーバーライドすればいい。

class Parent < AciveRecord::Base
has_many :children, :dependent=>:destroy

alias :destroy! :destroy

def check_destory
    if # 自分と子が全員削除可能
      return self.destory!
    end
end

def destroy
    self.deleted = true
    return self.save
    retrun check_destroy
end

end

てな感じ。

問題は子のほう。

メソッドを普通にオーバーライドすると、親の方が削除された時に、
自動的にdestoryが呼ばれるので無限ループに陥ってしまう。

で、苦肉の策で考えたのがこの方法。

class Child < ActiveRecord::Base
belongs_to :parent

def destroy
    if caller.to_s =~ /.+has_many_dependent_destroy_for_message_receiver_relations.+/
      return super
    else
      self.deleted = true
      self.save
      return self.parent.check_destroy
    end
end

end

callerで呼び出し元をたどって、
そこにhas_many_dependent_destroy_for_message_receiver_relations
(関連で:dependent=>:destroyを設定したときに、自動で呼び出される)
が含まれていたら親が削除された一連の動作で削除されていると判断して、
superを呼び出し、
それ以外はフラグを設定してそこで処理を握りつぶすという方法。

これなら、親が削除されたとき以外は削除されずにすむ。

callerのチェックとかってあんまりやりたくないんだけど、
この方法ってなんか問題あるのかしら。

滅多に使わない方法なのでちょっと悩む。
てか、なんかほかのもっといい方法があったら教えてほしい。

ActiveRecordで関連先がロードされているかどうかを判定する。

r2o — 2010-02-03T17:47:19+09:00

Railsアプリの最大のボトルネックとなりうるのはSQLとのやりとりである。
（Erbのレンダラーだという話は置いておく)

なので、Railsアプリでチューニングを行う時に真っ先に手をつけるのは
AR.find系のDBアクセスな部分になる。

ちょっとしたアプリを作れば、(普通にモデリングしている限り)複数の関連モデルができあがる。
この場合、チューニングのポイントはEagerLoadingにあり、
:hoge has_many :fugas
:fuga has_many :piyos
という関連にある場合は、一発ですべて取得できるこれは非常に便利。

Hoge.find(id, :include=>{:fugas=>:piyos})
とやれば、すべての関連をインスタンス化した状態で取得できる。

これは便利なので、結構めくら滅法使ってしまう。
関連先をループで回して表示したりすることがあるときは、これだけでかなりのチューニングになる。

さて、
ここからが本題。

たいていの場合、親になるモデルをインスタンス化するのはコントローラーの責務になる。
(当たり前ですが)

で、ちょっと複雑なことになったモデルクラスで、
parent.childlen.find(:all, :conditions=>[conditions])
みたいに取得するか、find_by_sqlするか、
それともループを回して配列にコピーするのがいいのか、
判断に迷うことがある。

こんな時、すでにEagerLoadingでロードされているのか、
はたまたロードされていないのか判断ができれば処理分岐で対応できる。

loaded?

これで判定がつく

parent has_many :children

だったとき、parentクラス上で、

if self.childlen.loaded?
# ループで回す処理
else
# DBアクセスを伴う処理
end

という感じ。

ちなみにテスト上では反映されないので注意。

ActiveRecordでINが使えない・・・

r2o — 2010-02-02T18:21:56+09:00

ActiveRecordのfindメソッドの:conditionsオプションって、INを判ってくれない・・・

class Hoge
:has_many :relations
:has_many :fugas, :through=>relations

class Fuga
:has_many :relations
:has_many :hoges, :through=>relations

class Relation
belongs_to :hoge
belongs_to :fuga

とあったとして、Hogeインスタンス上から、
Fugaインスタンス配列を元にRelationインスタンス配列がほしかったとする。

ナチュラルに考えて試してみる
self.relations.find(:all, :conditions=>["fuga_id IN (?)", fugas])
# nil

じゃあID配列で
self.relations.find(:all, :conditions=>["fuga_id IN (?)", fugas.map{|f| f.id}])
# nil

それじゃあID配列をjoinしてカンマ区切りに
self.relations.find(:all, :conditions=>["fuga_id IN (?)", fugas.map{|f| f.id}.join(',')])
# 最初の一つ目だけ

find_by～ならどうだ！！
self.relations.find_by_fuga_id(fugas.map{|f| f.id})
# 最初の一つ目だけ

まあ、当然ですよね・・・

結局find_by_sqlに頼ってしまうのね・・・

Relation.find_by_sql("SELECT * FROM relations WHERE hoge_id = #{self.id} AND fuga_id IN (#{fugas.map{|f| f.id}.join(',')})")

ActiveRecordって、ある一線を越えるとSQLを直接叩く方が早くてわかりやすいよね・・・
ちゃんちゃん

RadRailsの[identical code structure　～]ワーニングを消す

r2o — 2010-02-02T17:46:28+09:00

AptanaRadRailsを愛用しております。
NetBeansよりもコードアシストがよくなかったりとか、いろいろアレ気なところも多いIDEですが、
まあ、手になじんでいるのもあって愛用しています。

しかし、先日アップデートしてから非常にウザいワーニングが出まくりました。

identical code structure　～

というワーニングが、コードのありとあらゆるところに出まくってます。

「似たようなコードがほかにもあるから、メソッド化してDRYを保てよ～」という意図らしいですが、

UnitTestのコードとか、
ActiveRecordのFindメソッド呼び出しとか、
ちょっとしたハッシュの定義とかでも出まくる。

確かにぱっと見似たコードですよ・・・
でもこれ以上どうしようもないじゃん。
あんたちゃんと見てないでしょ・・・という感じ。

はじめはいちいち[Igonre this warning]とかをクリックして消していたけど、
あまりにもウザ過ぎる。

で、肝心の消し方。

Window->Prefanceから
Ruby-Erorors/Warnings-Duplicate Codeで
Enable checking my code for duplicate AST structuresのチェックを外す。

環境の再構築をしているらしく、しばらく待たされるけど、
これでウザいワーニングは出なくなりました。

本家のTracにも載ってたので、世界中からウザいと思われてたんでしょうね・・・

FactoryGirlの関連での注意

r2o — 2010-01-25T10:44:54+09:00

FactoryGirlで、
関連を表現したいときは
fuga belongs_to :hogeだったとすると

Factory.define :hoge_name, :class=>Hoge do |h|
h.name 'name'
end

Factory.define :fuga_name, :class=>Fuga do |f|
f.name 'fuga'
f.hoge Factory(:hoge)
end

と書けるんだと理解していた。ブレース（｛｝）で囲む必要があるのは、遅延ロードしたいときだけ、
という認識だったんだが、どうも違うみたい。

きちんとブレースで囲んで、
f.hoge { Factory(:hoge) }
とやってやらないと、rakeでエラーが帰ってくる。

どうやらFactoryGirlがDBのテーブルにfuga.hoge(関連名そのままのカラム)を探しに行くらしい。

FactoryGirl導入

r2o — 2010-01-20T20:39:33+09:00

新しいプロジェクトでテストをきちんと書くのに、
どうもリレーションが多いモデルなので、
まじめにFixtureを書こうとすると気が狂いそうになる。

特に、Railsのバージョンを2.3.5に変えたので、
IDが自動的に生成されちゃうので、なおのこと関連どうかけってよ・・・orz
なことに。

とりあえずFixtureのヘルプをみるも、omapを使え、とか書いてあるし。
調べてみるとかなりめんどくさそう。
ということで見つけたのがここ

なるほどねえ・・・
ということで導入決定。

親切に書いてあるけど、一応本家を参照しつつやってみる。

しかしまあ、どこも今はRSpecが標準らしく、
使い方はどこもRSpec向けの設定ばかり。

その上なんかテストの形式も変わってるし・・・
test "hoge" do　て何？
という感じですっかり時代に取り残された気分。

まあ、とにかくfactoriesディレクトリを作成して*.rbファイルを作り、
中にFactory.defuineなものを書いて設定するとよし。

ただ、Fixtureと違って自動的にロードしてくれないので、
各テストのsetupメソッドでファクトリを呼び出してインスタンス化とかしておかないとだめ。

逆に、細かくセーブ前、セーブ済み、属性のみ、スタブのみとかコントロールできるので
それはそれでいいかも。

というわけで、ちょっと使い込んでみます。

#　調べている時に、YAMLの中に<%= %>でRuby記述できることを今回初めて知ったのは内緒

白い烏