ActiveRecord の attribute 更新方法ってどんなものがあって、それぞれどんな違いがあるかご存じですか? 案外色々とあったので表にまとめてみました。リファレンスやソースコードを参考にしつつ、Rails 4.2 でテストしています。 単一の attribute 更新 メソッド 保存 バリデーション(*1) コールバック(*2) readonly チェック(*3) updated_at の更新 補足 使用例
ActiveRecord の attribute 更新方法ってどんなものがあって、それぞれどんな違いがあるかご存じですか? 案外色々とあったので表にまとめてみました。リファレンスやソースコードを参考にしつつ、Rails 4.2 でテストしています。 単一の attribute 更新 メソッド 保存 バリデーション(*1) コールバック(*2) readonly チェック(*3) updated_at の更新 補足 使用例
create_table "weapons", force: :cascade do |t| t.integer "girl_id", limit: 4 t.string "name", limit: 255 t.datetime "created_at", null: false t.datetime "updated_at", null: false end のように自動的に limit: 4 が付与されています。 あれ、以前のバージョンでは limit なんて付かなかったのに…。 そして僕はこう思いました。 「あれ? 外部キーが 4 桁の整数だと 1 万件以上のレコードを保持できなくね?」 でも、むろんそんなことはなく、それは非常に初歩的な勘違いでした。 Rails のドキュメント を見ると、 :limit - Requests a maximum column length. Th
users というテーブルに定義されているカラム情報を取得する方法のメモ。 使うAPI: Ruby on Rails API columns() テーブル名からモデルクラスを参照し、それに.columnsメソッドを使うと取得できる。 # テーブル名から、定義されているすべてのカラム定義を取得 Module.const_get('users'.classify).columns # 特定のカラムの情報を取得(例えば `id`) Module.const_get('users'.classify).columns['id'] # 特定のカラムから定義の一部を取得 col = Module.const_get('users'.classify).columns['id'] col.type # データ型を取得 カラムの定義の取得はこんなメソッドが用意されているっぽい。 コレで全てかわからんとです
MySQLは5.6系から時刻系のデータ型がミリ秒を持てるようになった。 やっとかよって感じですが。 最近持てるようになったので、Railsでは4.1まではMySQLに対してクエリを投げる時はミリ秒以下は問答無用で切り捨ててクエリを構築していた。 しかし、4.2betaが出る辺りで、MySQLにミリ秒対応のクエリを送るPRがマージされた。 MySQL 5.6 Fractional Seconds by arthurnn · Pull Request #14359 · rails/rails 既にMySQL側のカラムがミリ秒精度を持っている場合は特に問題は起きない。 けど、RailsでMySQL使っててRailsのバージョン上げようかって時に、そんなことはほぼ無いだろうと思う。 その場合、ちょっと面倒なことになる。 MySQL5.6がミリ秒以下の値を受け取った場合、精度が足りない部分は四捨五入
最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめに ごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと、次のようなテンプレー
I'm Josh, a software engineer and technical leader. My work spans from hands-on projects building large platforms to leading some of the best-performing teams in our industry. I also run internationally recognised conferences and events, which bring people from all over the world to the heart of Leeds to learn, inspire and share stories. Get in touch
<!-- こっちはエスケープ処理が入る --> <%= 'a < b & c > d' %> <!-- こっちはそのまま出力 --> <%= link_to 'Qiita', 'http://qiita.com/' %> こんな機能を実現するために、Railsでは通常のString型以外に、Stringを継承したActiveSupport::SafeBufferという型があって、後者ではHTMLエスケープなしで出力していいかを記録する機能が付いています1。ERBの出力では通常の文字列ならエスケープをかけて、SafeBufferはそのまま通す、ということをしています。 SafeBufferの生成 もちろんnewで作れなくもないのですが、通常は以下の2つのどちらかの方法で生成します。 '文字列'.html_safeというようにhtml_safeメソッドを呼び出す html_escape('文字
僕はRailsでController書いている時に一つのactionについて、こんな風にspecを書く事が多いです。 subject(:response) do # ←ココ get :index end it { expect(response.status).to eq 200 } これは普通に考えると、rspec-railsで自動的にresponseを作ってるし、既にあるものを上書きしているようで気持ち悪いところもあるんですが、get(post, putなども同様)の返り値も同じなのでまあ従来と同じようにresponseを使ってテストできます。 なぜわざわざsubject(:response)と書くのか まずsubjectを使うと「ここではこれをテストするんだな」と分かりやすくて個人的に好きというのがあります。 その上でsubject(:response)と書かずにsubjectとした
この2つのメソッドは同じような用途で使えますが、どのような使い分けをすればいいのかをまとめてみました。 # File activerecord/lib/active_record/relation.rb, line 222 def find_or_initialize_by(attributes, &block) find_by(attributes) || new(attributes, &block) end find_byとnewの引数に同じattributesが渡される。 なので、下記のようなJOINしたテーブルを検索条件に含めるとActiveRecord::AssociationTypeMismatchの例外が発生する。
Railsでバッチ処理を書く仕事があって、どちらにするべきか迷った。 迷ったのでググったら以下の記事を見つけた。 stackoverflow.com 要約すると script/runner は実行時にRailsアプリを起動する。これは rake の :environment と似ている Railsの起動は時間が掛かるので避けられるならrakeにして避けるべき それ以外はほぼ同等 ということなので、Railsのモデルを使うバッチはrunnerで、それ以外はrakeにする方が良さそう。 個人的には、 -e で環境を指定できる クラスのメソッドを直接呼べるのでテストが書きやすい(rakeだと結局処理を別のクラスに起こさなければいけない) という点からrails runnerを使うことにした。
こんにちは、tahara です。 Rails システムでのバウンスメール処理ってどうするのがいいんでしょう? ベステプラクティスではないかもしれませんが、弊社でのバウンスメール処理方法を書いてみたいと思います。 まずメーラークラスで return_path にバウンスメール受信用のアドレスを指定します。 class Notifier < Jpmobile::Mailer::Base # ActionMailer::Base include BouncedMailFilter default(from: 'from@expamle.com', return_path: 'bounce@example.com') ... end 上記メーラークラスで include しているクラスでは、 バウンスメール DB にメールアドレスが登録されているかチェックして、 登録済みのアドレスにはメールを送信
「SESで不達メールが多いから、対策してくれなかったらSES止めるよ」って過去にAWSから言われたことがあって、そのときの対応メモを書きだしてみた。 対応の基本的な流れ SESは不達メールがあった場合に特定のURLに対してリクエストをjson付きで投げてくれるので、それを特定のURLでうけてJSONパースして、そのパースしたJSONの中にメールアドレスがあるので、それをブラックリストテーブルか何か作ってINSERTして、メール送信の時はそのブラックリストテーブルを見て、送っていいメールアドレスいいか判定するって感じ。 AWSの設定はここを参考に。 Amazon SESのBounce SNS通知をRailsで処理する|WEBデザイン Tips Railsのソースはこんな感じ。 app/controllers/api/aws_controller.rb # # AWSから飛んできたリクエストを
やりたいこと すべてのRakeタスクの前後で、開始と終了のメッセージを表示したい。 毎回出るのは鬱陶しいので、指定したときだけ表示したい。 いろんなところにpとかRails.logger.infoのような処理を書きたくない。 実装 desc "Setup an account" task setup_account: %i(common) do logger.debug "creating account..." logger.info "created account!" end # Extend logger to the main object def logger Rails.logger end desc "Setup a common setting for every tasks" task common: %i(environment) do Rails.logger =
CrowdWorks Advent Calendar の9日目に入るはずだったポストです。元々は、問題提起とその解決篇をセットにしてご紹介するつもりだったのですが、話が壮大になりすぎて僕の文章力ではまとめきれずに挫折した挙句に〆切に間に合わなくなってしまいました リベンジとして、問題提起の部分だけをピックアップしてご紹介する形にします。解決篇はバッサリ省略。どこか別のポストで紹介できればと思います。アドベントカレンダー的には数日遅れで申し訳ないですが、何かのご参考になれば。 結論 先に結論から書きます。 データ集計で ActiveRecord は忘れろ 用途に合った適切なツールを使おう 前提 ここで言う「データ集計」というのは、だいたいこんな感じのモノを指しています。 サービスのデータベース (RDB) に蓄積された情報を取り出してきて 日次や月次の数字を表とかグラフの形式で見えるようにし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く