ActiveRecord::LockWaitTimeout, ActiveRecord::Deadlocked, ActiveRecord::ConnectionTimeoutError が起きた時に原因調査に役立つ情報を表示する gem を作った
それなりの規模のサービスを運用していると、不可解なエラーに遭遇することはよくあるものです。その中でもデータベース関連のエラーは一見難解な問題に見えるかもしれませんが、原因調査に役立つ情報をさえ出力すればたいていの場合は容易に原因を特定できるものです。というわけで、Rails でよく遭遇するエラーの調査に役立つ情報を出力する gem を作成しました。 activerecord-debug_errors 現在次のエラーをサポートしています。 ActiveRecord::LockWaitTimeout (MySQL のみ) ActiveRecord::Deadlocked (MySQL のみ) ActiveRecord::ConnectionTimeoutError 以下、具体的な例を用いてどのような情報が表示されるか説明します。 ActiveRecord::LockWaitTimeout Ac
Railsでスーパータイプ/サブタイプを表現する方法を比較してみる - Qiita
はじめに Railsでスーパータイプ・サブタイプの表現する方法は以下のように3つ存在します。 単一テーブル継承(STI) 具象クラス継承(CCI) クラステーブル継承(CTI) Railsの機能としてSTIがサポートされているため、何も考えずにSTIを選んでしまうことが多い(かつては自分もそうだった)ような気がしますが、 それぞれメリット・デメリットがあるため適切に使い分けるといいことがあります。 まずはそれぞれの簡単な説明をしていきましょう。 それぞれの説明 ここでは例として、次のようなケースをかんがえてみます。(ちょっと無理やりですけどつっこまないで…) Music というスーパータイプを持つ、 Classical と EDM という２つのサブタイプがあります。 Music は name 属性を持っています。これは当然２つのサブタイプ両方に必要な属性です。 また、Musicは抽象クラス
[Rails]STIから脱却してCTIでポリモーフィックを実現する - Qiita
Ruby on Rails Advent Calendar 2017の24日目の記事です。 SQLアンチパターンやPofEAAで「オブジェクト指向設計で抽出されたスーパークラス・サブクラスから成る継承階層をリレーショナルデータベースのテーブルとして実装するためのパターン」として具象テーブル継承、クラステーブル継承、単一テーブル継承(STI)の3つが紹介されています。 みんなRailsのSTIを誤解してないか!? その中でRailsはSTIはサポートされてますが、その他2つは自分で頑張ってポリモーフィックを実現しないといけないです。 STIを使わない理由としては NULLを許容したくない UpdateではなくInsertでデータ保存のフローを作りたい has_manyなデータはSTIだとjson型などスキーマレスになる あたりでしょうか。 今回はクラステーブル継承を実現する方法を書きます。デ
![[Rails]STIから脱却してCTIでポリモーフィックを実現する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/19ba8a807fd8e5ef373396d199502456a9911f2b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUmFpbHMlNURTVEklRTMlODElOEIlRTMlODIlODklRTglODQlQjElRTUlOEQlQjQlRTMlODElOTclRTMlODElQTZDVEklRTMlODElQTclRTMlODMlOUQlRTMlODMlQUElRTMlODMlQTIlRTMlODMlQkMlRTMlODMlOTUlRTMlODIlQTMlRTMlODMlODMlRTMlODIlQUYlRTMlODIlOTIlRTUlQUUlOUYlRTclOEYlQkUlRTMlODElOTklRTMlODIlOEImdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTczMWEyNWVhOWQzMTZlMTI1ODI2NDVkNjI0N2ZhOGY3%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBha2ljaGltMjEmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWI3MTg3MzNhNzc2N2U2NzRiYWMxNzM0YzU3YTA2YThh%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3Dc61249dc813f5dafe51a5d59acd14ba9)
【Rails】レプリケーション対応によりDB負荷を半分に減らした - Qiita
こんちは freee K.K. という会計・給与などの クラウドサービスを提供している会社にて会社員をやっとります @futoase です。 今日は弊社サービスで利用しているDB(RDS)の負荷を半分に減らしてみた、 ということで軽く書いていきたいと思います。お付き合いください。 今期ずっと見続けられてるアニメは、 ゆるゆりとおそ松さんです。 ここで話すRuby/Ruby on Railsの世界とは Ruby 2.1系 Rails 4.2系 以上の世界観となってます。 Ruby 2.1系なのは今月中に2.2にします...(2.3が出てしまう前に...) ベンチマーク方法 について予め言っておきますと、 nginxで収集したaccess.log(staging環境なので開発者がアクセスしたログしかないですよ)を元に 特定のController#Actionへの負荷計測をsiegeに食わしてシ
Ridgepole で主キーを変更する方法（「id」カラムを作らないようにする方法） - 約束の地
Ridgepole Active Record ほぼ準拠のマイグレーションツールです。 「id」カラムの除去 Ridgepole でごく普通にマイグレーションをすると、「id」というインクリメンタルな主キーのカラムが生成されます。新たにデータベースを生成する際には問題ないとは思うのですが、既存のデータベースのマイグレーションをする場合には不要なことも少なくありません。 「id」カラムを除去するには、create_tableのオプションにid: falseを付与すればよいです。具体的には以下のとおりです。 create_table "テーブル名", force: :cascade, id: false,... do |t|... 新しい主キーの設定 「id」カラムを除去しただけですと主キーが見失われますので、主キーを設定してやります。主キーの設定をするためには3つの記述を行う必要があります。
Rails5.1の主キーbigint移行
RailsのPRIMARY KEY(id)はデフォルトでAUTOINCREMENT付きINTEGERですが、Rails5.1でより大きなレコード数を扱えるようBIGINTに拡張されました。 この影響で、ridgepoleでRails5.0以前に作成したアプリケーションにスキーマを適用すると以下のような警告が表示されます。 [WARNING] Primary key definition of `versions` differ but `allow_pk_change` option is false from: {:id=>:serial} to: {} Primary keyを変更するには、以下のようにridgepole 0.7.1で追加された--allow-pk-change（主キー変更を明示許可）を追加する必要があります。 $ ridgepole -c config/data
railsで複合主キーをやめるmigration - Qiita
概要 railsのシステムでは複合主キーは認められてません。全てテーブルがidという自動採番の主キーを持つのが決まりです。 それはわかっていたのですが、多対多の中間テーブル、例えば、モデルで言えば下記ようなものです。 class User < ApplicationRecord has_many :user_skills has_many :skills, inverse_of: :users, through: :user_skills end class Skill < ApplicationRecord has_many :user_skills has_many :users, inverse_of: :skills, through: :user_skills end # これが私のいうところの中間テーブルです。 class UserSkill < ApplicationReco
RailsのArelを調査してみた - Qiita
RailsのActiveRecordで想定通りのSQLクエリが発行されずに辛い思いをしたので、SQLまわりのソースコードを読んでいたらArelというものに当たりました。 どうやらこれがrailsっぽくSQLクエリを書ける機能を提供しているようなので、勉強したことをまとめます。あまり細かいことは気にせずに、Arelを読み解く上での基礎を理解することが目標です。 ソースコードをちゃんと読んだ経験が少ないのでとんちんかんなこと書いてないか不安ですが、温かい目で見てもらえればと思います。 間違っている箇所あればコメント欄よりお願いします。 Arelとは ArelはActiveRecordの内側でwhereやselectのメソッドチェーンからSQLを生成する役割を担っています。またDBによってSQLの文法が若干違ったりしますが、その差異を吸収してくれるのもArelです。 rubygemsによるとAr
ActiveRecordに限界を感じArelでサブクエリを頑張って書いてみた - Qiita
はじめに railsを触り始めて4ヶ月が経ち、「ActiveRecordってSQLを知らなくても書けるってすごいなぁ」 と思っていた自分に変化が訪れました。その変化とは、「何でActiveRecordって全部纏めちゃうんだよ。。。」 という気持ちが芽生えたことです。 今私が扱っている案件では、「複数のテーブルから、ある条件のレコードの件数を、タイムアウトなしで取得したい」 という状態になっています。 一例ではありますが、以下のようなサブクエリを使用しないscopeを複数チェーンして、各条件の件数を取得していました。 scope :select_page_views_count, -> do left_joins(:page_views) .select("COUNT(DISTINCT page_views.id) AS page_views_count") .group("#{table_
Rails + PostgreSQL で論理削除と一意性制約を両立させる - Qiita
はじめに 最近読んだ @yuba さんの 論理削除と一意性制約を両立させる方法・DB製品別 という記事で、部分インデックス というインデックスについて知ることができました。そこで今回、Rails + PostgreSQL の環境でこの部分インデックスを活用するには具体的にどうすればいいかをまとめました。 TL;DR add_index の where オプションを使う。 問題 論理削除の機能を使った User モデルがあるとします。deleted_at 列に (削除された際の) 日付が設定された場合に論理削除されていると見なします。ここでは paranoia という Gem を使用していることを想定します。ただし、この記事では Gem を使用するかどうかやその種類は重要ではありません。 次のマイグレーションでは users テーブルの email 列に対して UNIQUE インデックスを作
ActiveRecordのコネクションプールの理解を深める - Qiita
昨日に引き続き、今は亡き経営工学科(通称「i科」)という学科のOBが担当させていただきます！ 今回は「へー」と思ったことが半年くらい前にあったのを当時社内の共有メモとして残していたのですがせっかくの機会なのでまた整理がてら引っ張り出してきました。 発端 rails3→rails4 rails4→rails5 とrailsのアップデートを粛々とやったことがあるのですがrails4→rails5へあげるときconnection_poolで怒られるというエラー場面に出くわしました。 エラー文面はこんなんです。 could not obtain a connection from the pool within 5.000 seconds (waited 5.000 seconds); all pooled connections were in use (ActiveRecord::Connec
Rails tips: 遅いクエリのログをDB設定変更なしで取るコツ（翻訳）｜TechRacho by BPS株式会社
アプリの種類を問わず、遅いクエリのログを読むのはパフォーマンス向上のためのリファクタリングで弱い部分を発見するよい方法のひとつです。 以前の私は、遅いクエリのログというとデータベースエンジンで生成されたログのことが念頭にありました。しかし、データベースの遅いクエリのログを取る独自のメカニズムを作れることをご存知でしょうか？RailsのActiveSupport::Notificationsモジュールを使うと、指定のイベントをサブスクライブできます。イベントのひとつに sql.active_recordがあり、これはデータベース操作のたびにトリガされます。 次のような感じで使えます。 ActiveSupport::Notifications.subscribe('sql.active_record') do |name, start, finish, id, payload| # inter
Railsのデータロック - Qiita
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
Rails: 闇雲にインデックスを付けてはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Don't index the kitchen sink! 原文公開日: 2015/07/09 著者: Jeroen Weeink サイト: Crafting Ruby 最近、使われてないインデックスを外す作業を行ってたのですが、やってみると出るわ出るわ。そのほとんどは、逆関連付けの不要なモデルのJOINの一部でした。次の例で考えてみましょう。 class ShoppingCart < ActiveRecord::Base has_many :shopping_cart_products has_many :products, through: :shopping_cart_products end class ShoppingCartProduct < ActiveRecord::Base belongs_to :shoppin
Railsエンジニアなら知っておきたい！RDBでindex作成を検討するときってどんなとき？ - Qiita
はじめに 前回に引き続き、またまたDBネタです(^o^) 前回：Railsエンジニアなら最低限これだけは知っておきたいSQLのJOINの動き 今回は、インデックスについてです。インデックスにはいくつか種類がありますが、 RDBで一般的に使われるB-treeインデックスについて書いていきます。 いきなりですが、インデックスは深い！かなり深い！バイカル湖くらい深いです。 ある程度の指針的なものはありますが、インデックスをどう設計するかの見極めは状況によって変わってくるようです。クエリの実行頻度、テーブルサイズ、カーディナリティ（カラム内のデータの種類の多さ）などなど。。 なので今回は、こんなときはインデックス作成を検討した方がいいというパターンだけザッとまとめる感じで行きたいと思います。 なお、今回の記事作成にあたっては、以下の本を参考にさせて頂きました。 そもそも的なところから分かりやすく書
ridgepoleで外部キー制約付きのテーブルを扱った際にハマった件 - Qiita
前提 rails 4.2.5 winebarrel/ridgepole v0.6.3 その1.export で 外部キー制約の名前が出力されない 問題 例えば以下のような参照整合性が設定されているテーブルがある # ブログエントリ class Entry < ActiveRecord::Migration def change create_table :entries do |t| t.timestamps null: false end end end # 記事に対するコメント class Comment < ActiveRecord::Migration def change create_table :comments do |t| # 記事テーブルへの外部キー制約が設定されたカラム t.references :entry, index: true, foreign_key: tr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FiNC Developers Blog — t-wadaさんとのSQLアンチパターン勉強会
リダイレクトの警告
How to Create Postgres Indexes Concurrently in ActiveRecord Migrations
Ensure dropping a database table is reversible