GitHub - stefankroes/ancestry: Organise ActiveRecord model into a tree structure
Ancestry Overview Ancestry is a gem that allows rails ActiveRecord models to be organized as a tree structure (or hierarchy). It employs the materialized path pattern which allows operations to be performed efficiently. Features There are a few common ways of storing hierarchical data in a database: materialized path, closure tree table, adjacency lists, nested sets, and adjacency list with recurs
Advanced Arel: When ActiveRecord Just Isn't Enough
The document discusses using Arel to construct ActiveRecord queries in a more object-oriented way compared to using literal SQL strings. It provides examples of using Arel to select columns, join tables, and add where conditions in a chained method syntax. Some benefits highlighted are that Arel avoids needing to know SQL syntax, provides Ruby syntax checking, and results in more readable queries.
has_many throughで，class_nameとかforeign_keyをちゃんと復習してみる - PartyIX
has_many，throughとかでモデルやテーブルの構成を考えるとき，どうしてもカラム名と関連づけるテーブルの名前が一致しなかったり，望み通りの命名で行けない場合がある． もちろん，一つのテーブルが，他のテーブルのレコードを複数持つだけなら，命名はスマートに決められるのだけれど． 今回の例題は，Userモデルに対するフォロー・フォロワーを実現すること． Userは一つのテーブルでなければならないことはわかりますよね． ということは，UserテーブルがUserFollowという中間テーブルを介して，Userテーブルのレコードをhas_manyするという形をとる． もうガリガリと書いていきます． まず，こういう，元から名前の統一が難しそうな場合はテーブルを先に作ってしまう． Userテーブル id name 1 poteto 2 hoge UserFollowテーブル id user_id
Railsのポリモーフィックアソシエーション [俺の備忘録]
Google+ボタン はてなブックマークボタン 更新日時: 2014年07月14日（月） 作成日時: 2013年07月17日（水） 前の記事 / 次の記事 似たようなモデルを扱っているからまとめてみたい気がするんだけど、 単一テーブル継承（STI）だとうまくいかなくて、 かといってガチでモデルを継承するとかいう危なそうなことはやりたくなくて っていう時はポリモーフィックアソシエーションで上手くいくかも知れない。 参考ページ 【Rails】ActiveRecord：単一テーブル継承(sti)とポリモーフィック関連を未だにぱっと思い出せないのでまとめ。 [Rails] 実用ポリモーフィック関連(基礎編) 何が出来るのか？ 参考ページで全て解決なんだけど、一応自分でもまとめ。 例えば、「日記」と「本」と「お店」があって、それぞれに日記の感想として、 本を読んだ感想として、お店に行った感想としてコ
ActiveRecord4でこんなSQLクエリどう書くの? Arel編 | Webシステム開発／教育ソリューションのタイムインターメディア
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 では、関連先のscopeを使うことができるmergeを紹介しました。mergeを使う事で、変更に強いクエリを美しく組み立てることができました。 今回は、ActiveRecord4で書きにくいSQLクエリたちを紹介します。 書きにくいクエリとは、具体的には以下のものがあげられます。 比較演算ORlikeleft outer joinunionサブクエリexists ActiveRecordでこれらのクエリを組み立てる場合、どうしても美しくない（SQL文字列をべったり書いてしまうような）書き方となってしまいがちです。 この処理を美しく書くためには、ActiveRecordだけの機能では足りず、ActiveRecordが内部で使っているArelというライブラリを使う必要がでてきます。 今回は、Arelを使って華麗にSQLク
クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
GitHubを使った複数人でのスキーマ管理 on Rails - so what
要約 Chefみたいなスキーマ管理ツール（Ridgepole）を使うと、GitHubを使ったワークフローでスキーマを管理できる（と思います、たぶん） RailsのMigrationsについての問題提起 Migrationsは便利な仕組みですがベストではないと常々思っていました。 具体的には、特定のマイグレーションを保留にしにくいとか、複数人で作業するとコンフリクトすることがあるとか。 大きめのRailsプロジェクトだと特別なワークフローを用意して解決しているんですかね…声出して行こうぜ！とか。 Chef的スキーマ管理ツール: Ridgepole https://github.com/winebarrel/ridgepole （デモ） 以前からそのようなそのような問題意識があって、たぶん Chef的な冪等性保証する（操作ではなく定義を書くたぐいの）ツールがあれば解決できそう、でも実際作るの大
ActiveHashを使ってRailsで区分値を扱う方法 | Webシステム開発／教育ソリューションのタイムインターメディア
Railsでの区分値の扱いについて考える の続きです。 区分値情報をDBに保存しておくか、アプリにのみ保存しておくのか、悩ましい所です。 DBに区分値を保存しておくと、ActiveRecordなオブジェクトになって扱いやすいという利点があります。 しかし、DBにもアプリにも区分値の情報(ProductTypeの1はLADIESであるといった情報）を持つ事になり、二重管理の状態となる可能性があります。 一カ所変えたら対になるもう一方の修正もしないといけない、という状態は、システム保守の観点からはよろしくありません。 私は過去にアプリ側に区分値情報を更新したのに、DB側に区分値情報を入れ忘れていた! という失敗を体験しました。 区分値情報をアプリ、DB両方に持ってるのはやめたい。でもActiveRecordライクなオブジェクトで区分値を扱いたい。 ActiveRecordのデータソースがcla
ActiveRecord のモデルを整理する7つのパターン - tkawachi Blog
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
Active Record で N+1 問題 - 日々精進いたします
最近会社でHibernateのN+1問題事例を調べてたんですが、ActiveRecordでも当然のように起こりますね。 BOOKSテーブルが、1対NでREVIEWSテーブルと関連を持っています。（BOOKSが1、REVEWSがN） 以下のコードでは、BOOKSテーブルを全件検索して、それに関連するREVIEWSテーブルのレコードを取得して、REVIEWSテーブルのBODYカラムを出力する。 Book.all.each { |book| book.reviews.each { |review| puts review.body } } このコードではBOOKSテーブルに対して1回のSQLが発行され、REVIEWSテーブルに対してはBOOKSテーブルのレコード数分のSQLが発行されます。N+1問題です。BOOKSテーブルとREVIEWSテーブルの多重度に関係なく、親テーブルを複数検索して、子テ
ActiveRecord::NestedAttributes::ClassMethods
Ruby on Rails 7.1.3.3 Module ActiveRecord::NestedAttributes::ClassMethods activerecord/lib/active_record/nested_attributes.rb Active Record Nested Attributes Nested attributes allow you to save attributes on associated records through the parent. By default nested attribute updating is turned off and you can enable it using the accepts_nested_attributes_for class method. When you enable nested att
ずくなし。 : Ruby on Railsで楽観的ロックをかける - livedoor Blog（ブログ）
排他制御には悲観的ロックと楽観的ロックがあります。 悲観的ロック： 自分が操作している情報（レコード）は他人も操作する可能性がある という観点から施される排他制御方法です。 具体例としては、あるレコードを操作する前に行ロックをかけてから参照・更新し、終了後にロックを解除する方法が取られるみたいです。 楽観的ロック： 自分が操作している情報（レコード）はまず他人は操作することがない という観点から施される排他制御方法です。 具体例としては、あるレコードを読み込んだときに、当該レコードの最終更新時刻を取得し、自分が更新するときにその更新時刻が変更されていた場合にロールバックする方法が取られます。 ただ、悲観的ロックを掛けた場合、他のトランザクションがロックの解放待ちになるため、スループットが低下すると言われています。 一般的なシステムでは楽観的ロックで十分と言われているので、楽観的ロックを掛け
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネストしたトランザクション内で ActiveRecord::Rollback を raise しても握りつぶされるだけだ | TECHSCORE BLOG | TECHSCORE BLOG
GitHub - k0kubun/activerecord-precount: N+1 count query killer for ActiveRecord
[Ruby] 例えば、ActiveRecord の connection_pool を止める - sonots:blog![[Ruby] 例えば、ActiveRecord の connection_pool を止める - sonots:blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/da78a05937633f7a2b4b2219826151c370cd607b/height=288;version=1;width=512/https%3A%2F%2Fparts.blog.livedoor.jp%2Fimg%2Fusr%2Fcmn%2Fogp_image%2Flivedoor.png)
Rails SourceCode Reading #1