Active Record Validations — Ruby on Rails Guides
This guide teaches you how to validate the state of objects before they go into the database using Active Record's validations feature. After reading this guide, you will know: How to use the built-in Active Record validation helpers. How to create your own custom validation methods. How to work with the error messages generated by the validation process. As you can see, our validation lets us kno
Railserなら知っておくべき地味だけど便利なメソッド - joker1007’s diary
Railsのバージョンは3.2.8時点のものです。(2012/8/21追記) 前回の冒頭で書いてたので、Rails版も書いてみようと思う。 要は、困ったらリファレンスマニュアルのそれっぽいところ見れば、 Ruby/Railsは大体解決してくれるよ(しかもスマートに)って感じなので、 悩んだらハマる前に一回公式に帰るのもいい手段だと思ってます。 でも、RailsのAPIリファレンスどこに何書いてるか分かりづらいと思う。 例えば、has_many関連には、実は:after_addとか:before_removeとか、 その手のコールバックをProcで渡せるんだけど、メソッドの説明の所に書いてないんよね。 上の方のクラス全体の説明の所にAssociation Callbackって項目があって、 そこで地味に説明されてたりとか。 この辺、もしかしてpull request候補かな。 メインはAct
rails で id を BIGINT 型 + primary key + AUTO_INCREMENT する - scramble cadenza
イントロ rails のモデルは自動で id というカラムを作ってくれますが、これは常に INT 型。 BIGINT 型にしようとしたら、結構ハマったのでメモする。 使っている database はmysql です。 (postgresql だとこの罠は回避できるのだろうか？) tl;dr 普通に頑張ると... db:migrate と db:setup の実行結果が異なる migration ファイルの内容が、schema.rb に(一部)反映されないため db:migrate と db:setup の実行結果が異なると、 db:rollback ができなくなるので、辛くなりそう。 db:migrate か db:setup どちらかを使わない、という運用方式もある だが、面倒くさいので、そういうことを意識したくない 解決方法は 2 つ format_schema = :sql kami
Rails 5から導入されたmigration versioingについて
Rails 5から、migration versioingという機能が追加されました。 これは、generatorが生成するマイグレーションファイルに、Railsのどのバージョンで生成されたマイグレーションファイルなのかという情報を付与し、そのバージョン情報によりAPIの挙動を変える、というものです。 実際にRails 5.0.beta1でマイグレーションファイルを生成してみると、以下のような内容のファイルが生成されます。 $ ./bin/rails g model book name:string # db/migrate/20160124064808_create_books.rb class CreateBooks < ActiveRecord::Migration[5.0] def change create_table :books do |t| t.string :name t
Rails で fat model を避けるための、あまり知られていない方法について - おもしろwebサービス開発日記
このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects
酒と涙とRubyとRailsと
asin: 4797363827 title: “[Rails高速化] ページキャッシュ、N+1対策、SQLチューニング” category: Rails 🐯 tags: [Rails, Ruby, Gem]『Cookpadではユーザーへのレスポンスタイム 200ms/reqを目標にしている』に感銘を受けて書き始めたこの記事ですが、『パフォーマンス・チューニングやオススメGem in 「Rails勉強会@東京 第88回」』でいろいろ教えてもらったり、最近関わっているサイトのリニュアールで試行錯誤したので、忘備録も兼ねて記事をアップデートします！ 🚕 目次(1) N+1問題の対策 (2) Railsのキャッシュについて (3) 開発中ならrack_mini_profiler (4) 運用中なら断然NewRelicがおすすめ (5) mysqlの簡単チューニング 🚌 (1) N + 1問
RailsのTransactionの使い方 - Qiita
なぜTransactionが必要なのか Transationの目的は、あるいコードブロックにあるSQL文の変更を、全部成功することを守るための存在である。Transactionにより、データの統一性を保ことができる。銀行などの受け入れと引き出しの処理には必要でしょう。二つの処理の中一つが失敗すると、コードブロークにあるSQL処理を全部ロールバックされるのが、Transactionの特徴である。 ActiveRecord::Base.transaction do david.withdrawal(100) mary.deposit(100) end Transationのロールバックが発火条件 Railsでは、ロールバックが発火するには、「例外」が必要である。これがTransactionを使うときのもっとも重要なことである。 例えば、Railsでは #update_attributeは例外を
ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita
ActiveRecordでN+1クエリを潰すためにeager loadingを行う場合、preloadやincludesやeager_loadが役に立つ。 Preload, Eagerload, Includes and Joinsという記事にそれらの違いがよくまとめられているんだけど、includesが挙動を変える条件があまり正確に書かれていなくて自信が持てなかったし、そもそも記事が古いのでRails4.1.5のソースを読んで調べた。 せっかく調べたので、全体を通して日本語でまとめてみようと思う。 User.joins(:posts).where(posts: { id: 1 }) # SELECT `users`.* FROM `users` INNER JOIN `posts` ON `posts`.`user_id` = `users`.`id` WHERE `posts`.`id
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
