RailsアプリでSQLを発行している場所を特定するのにquery_traceとかいうgemがぐう便利 - Qiita
RailsアプリでクソみたいなSQLを大量に発行している箇所を知りた〜い Railsアプリで、発行されるSQLの量を頑張って減らすときに、例えばN+1問題をなんとかしたいと思ってBulletとかいうgemを入れて、N+1を出している箇所を特定したりする場合は多いと思います。 実際bulletはすっごい便利なんですが、N+1問題を発生させている箇所を検出できない場合があったり、そもそもの原因がもともと書いているロジックが悪くて、それの見直しで解決しなきゃいけない場合だったりとかする場合がよくあると思います。 で、それで前々から **「このTerminalに出てくるSQL文、Railsアプリのどこが出してるのかな〜それがわかったら超ベンリなのにな〜〜〜」**と思ってました。 会社の同期に聞いたらめっちゃ便利なのがあったんで以下に書きます。もっと早く知りたかった。 query_traceをぶっこ
ActiveRecord4でこんなSQLクエリどう書くの? Arel編 | Webシステム開発／教育ソリューションのタイムインターメディア
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 では、関連先のscopeを使うことができるmergeを紹介しました。mergeを使う事で、変更に強いクエリを美しく組み立てることができました。 今回は、ActiveRecord4で書きにくいSQLクエリたちを紹介します。 書きにくいクエリとは、具体的には以下のものがあげられます。 比較演算ORlikeleft outer joinunionサブクエリexists ActiveRecordでこれらのクエリを組み立てる場合、どうしても美しくない（SQL文字列をべったり書いてしまうような）書き方となってしまいがちです。 この処理を美しく書くためには、ActiveRecordだけの機能では足りず、ActiveRecordが内部で使っているArelというライブラリを使う必要がでてきます。 今回は、Arelを使って華麗にSQLク
酒と涙と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開発を補助するGoogle Chrome機能拡張·RailsPanel MOONGIFT
RailsPanelはGoogle ChromeのインスペクタにRails用パネルを追加するソフトウェアです。 Ruby on Railsは開発速度を飛躍的に向上してくれますが、サーバサイドのログとWebブラウザでの表示を交互に確認するのは面倒に感じていました。そこで使ってみたいのがRailsPanelです。 Google Chrome機能拡張をインストールします。別途Rails側でのライブラリインストールも必要です。 サンプルです。インスペクタにRailsPanelが追加されています。 実行されたSQLも確認できます。 レンダリングに使われたファイルも確認できます。MacVimなどであればここからクリックして開けます。 設定です。TextMate、MacVimが対応に上がっています。 RailsPanelを使えば実行されたアクション、使われたテンプレート、実行されたSQLが一目で確認でき
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
https://2021.pycon.jp/time-table/?id=273396 Webアプリ開発とデータベースマイグレーションには密接な関係があり、Pythonでよく採用されるDjangoやSQLAlchemyには、DBのスキーマを変更するマイグレーション機能があります。一般的に、プログラムを実装するときはリポジトリでブランチを作りそれぞれのブランチで実装作業を進めます。Webアプリの開発でも同様ですが、各ブランチでDBスキーマを変更する場合には注意が必要です。例えば、複数のブランチで同じテーブルのカラムを追加して使いたい場合や、DBスキーマの変更が競合する場合は、ブランチのマージ時に競合してしまいます。多くの機能を並行開発したり、マージするまでの期間が長い場合には、このような競合が増えてしまいます。 このトークでは、Djangoを例に、データベースマイグレーションの仕組みから、実
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
