PCがあれば何でもできる!スマートフォン用の表示で見るPCがあれば何でもできる!へっぽこアラサープログラマーが、覚えたての知識を得意げにお届けしますこの広告は、90日以上更新していないブログに表示しています。Ruby2回目の「Dynamoid」の不便な点と改善方法についてのお話です!前回の記事はこちら。:integerendこんな感じで検索したとします。maleModelにsexのfieldを定義していないため、”sex=”のメソッドが無いと言って落ちます。#<User:0x000001065e4370>この動きのせいで、過去にゴミ属性を作っていると引っかかります。orz対処方法ということで、コードでDynamoidさんを説得してみたいと思います。エラーが発生している場所を調べます。endendself.class.undumpで取得したレコードの属性をハッシュ化し、#{key}=メソッドでModelの各fieldに値を退避させています。Modelにfieldを定義しないと、このメソッドが作られないため、落ちてしまうようです。そこで、メソッド実行前に、respond_to?を使って、メソッドの存在チェックを挟みます。書き換えは、Rubyのオープンクラスの特性を活かして、外部から書き換えます。@changed_attributes={}>さらにパフォーマンスを追求さて、動きはしたものの、上記の修正については、ややパフォーマンスが心配です。respond_to?はクラス内(継承、特異含む)のメソッドを全て探索するため、軽い処理とは言いがたいです。なり、かなりの負荷が予想されます。そこで、改良パターンを2つ考えてみました。改良パターンハッシュを利用するパターンDynamoidは、fieldを定義した際に、自動でModelクラスのattributesというハッシュに、属性情報が保存されます。そのハッシュを利用することで、respond_to?での余計なメソッド探索を防ぎます。endendbegin-rescueによる例外処理で回避するパターンレコード毎、属性毎に、探索を行わないため、ゴミデータが限りなく少ない場合は早いはず。ms安定して早いのは、ハッシュでした。例外処理の重さをあらためて感じます。ゴミデータ入りの行が限りなく少ない場合は、順位が入れ替わるかもしれませんね。将範フリーランス/エンジニア(主にサーバサイド、その他広く浅く)自宅の作業場は冷蔵庫の隣。キッチンエンジニアとして日々精進しています。(1)はてなブログをはじめよう!m_doi2さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。