アプリケーションの中にあるModelのレコードを数を調べたかったので、それをプログラムから動的に行う方法を考えてみた。 ActiveRecord::Baseのサブクラスを取ってくればいいはずだ!ということで、ActiveRecord::Base.subclassesを使うことにした。確認にはrails consoleを使った。 % rails c ActiveRLoading development environment (Rails 4.1.0) Frame number: 0/5 [1] pry(main)> ActiveRecord::Base.subclasses => [User (call 'User.connection' to establish a connection)] [2] pry(main)> UserというModelが取れたことはわかる。でも実はこのアプリケ
Ruby で DB を扱うちょっとしたスクリプトを書くとき、ActiveRecord で生SQLを使うと色々捗ることが多い。 そのためのメソッドをまとめてみた。 事前準備: establish_connection 作成・更新系: execute 検索系: select_all, select_one, select_rows, select_values, select_value プレースホルダ: sanitize_sql_array 事前準備 establish_connection DBとのコネクションを確立する。'mysql2', 'postgresql', 'redshift' など様々なアダプタが使える。 以下は接続設定の一例。 [MySQL] (要 mysql2 gem) require 'active_record' config = { adapter: 'mysql2
ActiveRecordでは、lockとやlock!メソッドを使うことで悲観的ロックを実現することができます。 ロック自体は、基本的にはSELECT … FOR UPDATEが発行されてロックがされますが、DBに依存するので実際に発行されるSQLコードを確認することが大切です。 動作確認 Rails 4.1 ActiveRecord 4.1 mysql2 0.3.7 MySQL Server 5.6.21 Mac OS X 10.10 目次 悲観的ロックとは MySQLの設定とモデルの準備 悲観的ロックの使い方 (WIP)悲観的ロックのテスト 悲観的ロックとは悲観的ロックとは、競合が発生する可能性が十分あるという状況に向いたロック手法です。 DB側でレコードをロックし、ロックされたレコードを更新できないようにします。 あまりに競合が発生する場合には、ロックにより処理が待たされる時間が多くな
はじめに みなさん、ActiveRecordの serialize や store は好きですか? 僕は 嫌い です。 serialize や store は原則として使わない方がみんな幸せになれると思っています。 なのでみなさんも serialize や store は使わないようにしてください。 以上! ・・・で終わったら意味がわからないと思うので、この件についてなぜダメなのかをちょっと詳しく掘り下げてみます。 そもそも serialize / store とは? serialize や store は ActiveRecord の機能の一つです。 text型のカラムに配列やハッシュなど、好きな形式のデータを放り込めます。 テーブルやカラムを追加しなくても自由にデータが保存できる 魔法のような機能 (注:皮肉)です。 サンプルコードを使ってこの機能を確認してみましょう。 以下の例では
Railsのdefault_scopeは悪だ!(default_scope is evil) ということらしいRubyRailsActiveRecord Rails Best Practiceのサイトを見ていたら、結構あおり気味なタイトルの記事があった。 default_scope is evil | Rails Best Practices 要約すると、Rails(ActiveRecord)の default_scope は2つの理由から使うべきではないとのことです。 default_scopeのオーバライドができない モデルをイニシャライズするときにdefault_scopeの副作用が影響する サンプルコードもあったので自分の環境でも試してみました。 以下の環境で試してみました。 Rails4.1.5 Ruby2.1.2 ベースとなるモデルは以下の様なUserクラスがあると想定(def
mergeはmergeでもHashじゃなくてActiveRecord::SpawnMethodsのmergeなのです。 join先のテーブルの条件で絞り込みたい class Entry < ActiveRecord::Base has_many :comments end class Comment < ActiveRecord::Base belongs_to :entry end 例えばブログのエントリーの公開・非公開がいつでも切り替えられるとして、非公開になっているブログのコメントを抽出したいな、と思ったとします。 公開・非公開かはentriesテーブルのpublished_atカラムにDateTimeがセットされているかされていないかで分かるとすると、以下のようなコードになると思います。 Comment.joins(:entry).where(entries: { publishe
2013年12月2日更新: 参照されることが多いので Rails 4 の情報を訳注として追記しました。また、Rails 4 に関する情報は、 WEB+DB PRESS Vol.73 が非常に参考になるので、一読をおすすめします。 この文章は Mitch Crowe 氏のブログより 2012年4月14日の記事を翻訳したものです。 The 10 Most Underused ActiveRecord::Relation Methods http://blog.mitchcrowe.com/blog/2012/04/14/10-most-underused-activerecord-relation-methods/ 昨日は ActiveRecord::Relation のコードに膝まで浸かって、使われているのをこれまで全然見たことがない面白いナゲットを思い出させてくれた。この記事で、十分に活用
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
Active Record Nested Attributesの記事の抜粋です。 accepts_nested_attributes_forは、親子関係のある関連モデル(Project has_many :tasks や Enquate has_many :questionsなど)で、親から子を作成したり保存したりするときに使える。 1対1の時 class Member < ActiveRecord::Base has_one :avatar accepts_nested_attributes_for :avatar end params = { member: { name: 'Jack', avatar_attributes: { icon: 'smiling' } } } member = Member.create(params[:member]) member.avatar.id
2013年08月20日10:29 Ruby いまさら聞けない!? accepts_nested_attributes_forの使い方 Railsのaccepts_nested_attributes_forを使い方を簡単に。 例えばBlogとArticleで1対多の関係の場合、Blogの作成時にArticleもまとめて作ろうとするときってありますよね。そういうときの話です。 まず、モデルでaccepts_nested_attributes_forを宣言し、 class Blog < ActiveRecord::Base has_many :articles accepts_nested_attributes_for :articles # これ! end class Article < ActiveRecord::Base belongs_to :blog end コントローラでは事前にAr
ActiveRecordでhas_manyを指定しているモデルを操作する画面を作る時に、以下の様な事で悩んでいた class Account < ActiveRecord::Base has_many :roles end class Role < ActiveRecord::Base belongs_to :account end # コントローラー側のメソッド内 def update account = Account.find_by(params[:id]) account.roles = [] #=> ここでrolesがdeleteされてしまう params[:roles].each do | role | # ... end unless account.save render :action => "edit" end end account.rolesにパラメータが来てないも
I am finding it difficult to easily see what attributes/properties exist on all of my model classes since they are not explicitly defined in my class files. To discover model attributes, I keep the schema.rb file open and flip between it and whatever code I'm writing as needed. This works but is clunky because I have to switch between reading the schema file to pick up attributes, the model class
Railsでは、ActiveRecordのhas_manyのasオプションとbelogns_toのpolymorphicオプションを使うことで、DBのポリモフィックのリレーションを簡単に実装することができます。 動作確認 Rails 4.1 ActiveRecord 4.1 目次 ポリモフィックリレーションとは ポリモフィックなテーブルの作成 モデルにhas_manyとbelongs_toを追加する 使えるようになるメソッド ポリモフィックの画面を作成 1. ポリモフィックリレーションとは説明のために次のER図を実装してみます。 記事(Article)とイベント(Event)にそれぞれコメント(Comment)を複数つけることができます。 記事用のコメントテーブル、イベント用のコメントテーブルとそれぞれ作ると、それぞれ同じような処理を記述しなければいけないため、コメントテーブルは参照先とな
INNER JOIN じゃないと不味いが joins だと N + 1 問題が発生してしまう場合にどうするかを調べた。 結論から言うと joins + preload または joins + eager_load を使うと INNER JOIN を使って結合した上で関連オブジェクトも即時フェッチしてくれる。 試したのは Rails 4.1.6。 joins + preload INNER JOIN で結合 クエリ複数回(指定した関連オブジェクトの分) 即時フェッチ > Post.joins(:comments).preload(:comments) Post Load (0.3ms) SELECT "posts".* FROM "posts" INNER JOIN "comments" ON "comments"."post_id" = "posts"."id" Comment Load
belongs_to や has_many で宣言した、 モデル間のアソシエーションの情報を取得するには、 ActionRecord::Reflection の reflect_on_all_associations メソッドを使えばいい。 ActiveRecord::Base は ActiveRecord::Reflection を include しているので、 モデルのクラスメソッドとしてすぐ使える。 # 全部 Task.reflect_on_all_associations # belongs_to だけ Task.reflect_on_all_associations(:belongs_to) # has_many だけ Task.reflect_on_all_associations(:has_many) 1 件だけ取得する reflect_on_association なんて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く