Rails複数データベース関連の資料まとめ
お仕事で今、Railsアプリケーションで複数DATABASEのサービスを開発していて、いろいろと悩むことが増えてきたので、勉強を兼ねてネットにあったドキュメントを収集していくつか読み込んでみました。俺得記事です。あともしよい資料とかあればぜひコメントください！ 🎳 クックパッドにおける最近のActive Record運用事情クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ マイグレーションは使っていない1,500以上のモデルがあり、複数人が作業しているため、互いの作業をブロックしないためにもマイングレーションでの運用は行っていない。 スキーマ管理ツール： Ridgepolewinebarrel/ridgepole - GitHubスキーマ管理ツール。テーブル定義ファイルにカラムを書き足すと、実際のDBのテーブル定義と比較して、 差分があればそのぶん
クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
インフラストラクチャー部の成田（@mirakui）です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか？ ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
ユーザとユーザを多対多で関連付けるモデルを共通化する - Hidden in Plain Sight
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
Ruby on Rails プラグイン - @nifty WebService
@niftyのウェブサービスの一覧と、@niftyのウェブサービスを使ったみんなのアプリケーションを紹介します。Ruby on Rails（ルビー オン レイルズ）はオープンソースのWebアプリケーション開発フレームワークです。 @niftyのサービスでは@nifty TimeLine、アバウトミー、ツクシィ、いたがきなどがRuby on Railsを用いて開発されています。 Ruby on Rails プラグインとは Ruby on Rails プラグインとは、Ruby on Railsで構築したアプリケーションに独自機能を追加できる機構の名称です。@niftyのポータル/CGMサービス用に開発したRuby on Railsプラグインをオープンソースソフトウェア（MITライセンス）として提供します。 ActiveRecordBrowser テーブルの管理機能を提供するプラグイン
ActiveRecordのようにTokyoTyrantを使う、MiyazakiResistanceを作りました - kaeruspoon
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 TokyoTyrantをActiveRecordのように気軽に使える、MiyazakiResistanceを作りました。Cabinet(内閣)、Tyrant(傀儡)という意味を見て、地方から傀儡政権に抵抗するというイメージが勝手にわいてきたのでした。 MiyazakiResistanceは、TokyoTyrantのテーブルデータベースを対象にしています。データスキーマのないTokyoTyrantに、あえてスキーマの制約を与えることで管理をしやすくしています。TokyoTyrantでは異なる種類のデータをひとつのデータベースに置くことはあまりないと想定してのことです(キー値がかぶるし)。 MiyazakiResistanceは、レプリケーションにも対応しています。マスターと複数のスレーブ構
SQLの条件を組み立てるRailsプラグイン Condition Builder 1.1 - こせきの技術日記
RailsでSQLの条件を扱う、Condition Builderプラグインが便利です。 最新版(1.1) http://blog.inquirylabs.com/2007/06/28/condition-builder-11/ 説明 http://blog.inquirylabs.com/2007/01/04/condition-builder-10-released/ 以前の記事 http://blog.inquirylabs.com/index.php?s=condition+builder&submit=Search Conditionクラスのメソッド一覧 通常、ActiveRecordに条件を指定する場合、:conditionsオプションで ["a = ? AND b = ?", 1 , 2] のような配列を指定します。この配列の構築をサポートしてくれるのがConditionBu
named_scopeについてくわしく - moroの日記
先日の金曜日に、社内でnamed_scopeの勉強会をやりました。 RubyKaigiで松田さんがしゃべった話がたいそう面白かったので、実際にnamed_scopeの実装を見てみよう、というテーマです。 | View | Upload your own 調べて改めて思ったんですが、これはまたよくできてますね。 method_missingを活用しまくっているという意味ではいつもの「イヤな予感」がするんですが、使い方がキレイで脱帽です。このあたりの「味わい」はスライド後半のコールシーケンスをご覧ください。複雑なことをやっているんですが、一度わかるとものすごく腑に落ちる感じが、何ともうまいですよね。うん。 今回取り上げたのはリリース版(AR2.1)のnamed_scopeですが、現時点でもいろんな機能が追加されてますのでまた先々も楽しみです。Railsレシピブックも改版する機会があったら(今回
has_manyな関連で、1アクションで複数のモデルを同時に保存するには？ - ザリガニが見ていた...。
前回までのhas_oneな関連に限定した、複数のモデルを同時に保存するコード まず、前回のコードは、あまりにも手抜きだったので、もう少しscaffoldに習った形式に書き直してみた。この後has_manyな関連に対応させることを目指して、以下のようにしてみた。 既にRails2.0もリリースされ、Rails1.1.6時代の書き方では動作しない状況（end_form_tagなど）になりつつありますが、自分の頭が追いついていないので、ここではRails1.1.6仕様なコードを書いて、Rails1.2.6環境で動作確認しています。 まずはモデルを生成して... script/generate model slip script/generate model journal マイグレーションの設定... # db/migrate/001_create_slips.rb class CreateSl
1アクションで複数のモデルを同時に保存するには？ - ザリガニが見ていた...。
今更ながら基本的なことかもしれないが（自分では今も悩み続けている）、業務システムで入力する部分を作っていると、しばしば2つ以上のモデルを同時に保存したい状況に陥る。例えば、伝票を入力する場合であれば、伝票は複数の明細行を持っているので、共通情報を保持する伝票(Slip)クラスと、明細行情報を保持する明細行(Journal)クラスに分けている。そのようなシステムで、Submitボタンを押した後の処理は、模範的にはどのようにすべきなのだろうか？ 保存する時には、以下の仕様を満たしておきたい。 class Slip {has_many :journals}; class Journal {belongs_to :slip}; な関連である。 検証エラーが発生したら... 保存は一切しない。 すべてのモデルの検証エラー情報を表示する。 Journalモデルの件数は可変である。 悩みのポイントは、S
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Pragmatic Patterns of Ruby on Rails - Ruby Kaigi2009
Ruby on Rails - ActiveRecord - — ありえるえりあ