論理削除gemを1年ほど保守してみて。重大な欠点にやっと気づいたポエム。 - 波打際のブログさん
はじめに kakurenboというgemはご存知でしょうか？paranoiaの欠点を克服すべく1年ほど前に私が開発を始めたgemです。(参考：Rails4と3で論理削除を行うためのGem Kakurenbo の紹介と今更論理削除Gemを実装した理由。 - 波打際のブログさん) issueやpullrequestを送信してくださる善意のコミッターの方々に支えられながら1年ほど保守をしてきました。その上で薄々は気がついていたのですが、どうしても認められなかった重大な欠点をハッキリと認識させられたのでポエムにしました。 論理削除gemの起源 kakurenboもparanoiaも、廃れてしまった acts_as_paranoid を再実装したものです。 これらのgemは導入するだけで、いつも使っているdestroyメソッドが論理削除メソッドに早変わりする素晴らしいgem...になるはずだったので
RailsでModelをDBから分割・整理する - リア充爆発日記
それなりの規模のRailsプロジェクトではよくFat Model問題とかFat Controller問題が課題になってくる。 で、Fat Model問題については、Concernsなどに振る舞いを切り出したり、そもそも「それって１つのテーブルに収める必要ある？」というものを分割するなどの対策がある。 後者については、http://kenn.hatenablog.com/entry/2014/03/05/081525 この記事がわかりやすいサンプルとしてUserモデルからProfileモデルをテーブルごと切り出す例を挙げている。 今僕が関わっているプロジェクトでも上記例のように姓名などはProfileに切り出してあり、その他も住所関連の情報をAddressに、「退会理由」みたいなめったにつかわない情報をExtraInfoに、といったように意味合いと使用頻度を考慮していくつか分割する設計になっ
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
Rails でシングルじゃないテーブル継承 - Qiita
この記事の目的 Rails の STI を使うようなケースで、STI の代わりに PostgreSQL のテーブル継承を使ってみる方法を紹介します。 STI とは Single Table Inheritance 単一テーブル継承 モデルクラスを継承で表現し、永続化部分はスーパークラスのテーブル１枚でまかなう STI の実装例（親クラス） class CreateCars < ActiveRecord::Migration def change create_table :cars do |t| t.integer :weight t.string :color t.string :type # STI 用のメタデータカラム t.timestamps end end end
Railsのdb/schema.rbの役割 - Qiita
db/schema.rbは何に使われるのか rake db:migrateなどをすると現在のスキーマが反映され、スキーマの確認などに便利なschema.rb。 ふと、1つのRailsアプリを分割して、複数のRailsアプリから同じDBを参照するようにしたくなったのだが、その際にどちらのRailsアプリにもdb/schema.rbを含める必要があるのか気になった。 db/schema.rbを削除してもアプリは動くのだが、 schema.rbには「It's strongly recommended that you check this file into your version control system.」と書いてあるので、本当に削除していいのか自信がない。 そこで、Rails4.1.5のソースを読んで、schema.rbがどんな用途に使われているのかを調査した。 schema.rbが
ActiveRecordでstrict_modeを無効にする - Qiita
Rails 4.0からActiveRecordにstrict_modeが導入され、デフォルトでは接続時にsql_mode = STRICT_ALL_TABLESをセットするようになりました。 これは、既に運用されているDBに接続する等なんらかの理由でMySQL側で適切な設定が行えていない場合有用な動作ですが、そうでない場合、サーバー側の設定を鑑みずにクライアント側が設定を上書きするべきではないでしょう。 そのため、database.ymlでstrict: falseと設定することでこの動作を無効にすることができましたが、Rails 4.2.0ではこの動作が変更され、strict: falseのときはstrictでない状態にするためsql_mode = ''をセットするようになりました。 MySQLのデフォルトのsql_modeに依存して既に通っていたはずのテストが通らなかったりすることがあ
Squerylの使用感とScala ActiveRecord - xuwei-k's blog
追記: 作者の方から、丁寧な回答をコメントでもらったので、ちゃんと読むといいよ！ いくつかblogに書いたり、tweetしているように最近Squeryl使ってます。 そして、今日2013年3月2日Scala Conference in JapanでScala ActiveRecordの発表を聞いて来ました https://github.com/aselab/scala-activerecord がしかし、会場で質問しようとしたけどできなかったので、Scala ActiveRecord自体への疑問と、ついでにSqueryl自体の使用してみての感想や疑問なども色々書いてみようと思います。 なお、真面目に使用を検討すればするほど、(元々心配性な正確も相まって)必要以上に(?)否定的というか懐疑的というか疑問点、不満点ばかり気になるので、それらを中心に書き連ねていきますが、ご了承ください・・・(´
ActiveRecordが発行するSQLをフックして色々やるためのライブラリArproxyを公開しました - 昼メシ物語
https://github.com/cookpad/arproxy http://rubygems.org/gems/arproxy これは何？ Arproxyを使うと、ActiveRecordが発行したSQLがDB Adapterによって実行される直前をフックすることができます。これによって、カスタマイズしたクエリログを出力したり、どこからクエリが発行されたのかをトレースしたりすることができるようになります。 Arproxyでは、DB Adapterのフック処理を以下のように定義します。これはクエリが実行されるたびにバックトレースを出力する例です。*1 class QueryTracer < Arproxy::Base def execute(sql, name=nil) Rails.logger.debug sql Rails.logger.debug caller(1).join(
ActiveRecordのコネクションプーリングをやめてみる - kaeruspoon
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 関連 : RailsでMysqlスレーブ群をロードバランサ経由で使用できる、FreshConnectionを作り始めました RailsのActiveRecordは、DBとのコネクションがプールされます。 アクセスごとにコネクションをはりなおすよりは、オーバーヘッドがない分、理にかなっているようにも思えます。 ただ、比較的大きめなサイトになってくると、はりっぱなしのコネクションが多くなりすぎちゃって大変なことになってきます(1サーバ1万コネクションとかなりかねない)。リソースは食うし、たくさんのスレーブを抱えているときにActsAsReadonlyableなどでちまちまやっていたらとても運用できません。スレーブなんてLVS+keepalivedでバランシングしちゃいたいところ。でもコネクシ
Rails(ActiveRecord)でデータベースへのコネクションプーリングをさせなくする - はまさき
ActiveRecordを使ったRailsアプリは，デフォルトでデータベースへの接続をプールするようになっています． ActiveRecordユーザとしては待ちわびたぜ！的な機能らしいのですが，設定等でこれをdisableすることが出来ず，LVS+keepalivedを介する場合にはロードバランシングが最初の接続時にしか為されずがなかなか厄介です． 対策として思いついたのは プールした接続を早い周期で捨てる LVS+keepalivedではなく，MySQL Proxyでバランシングする(Proxyへの接続はプール) そもそも接続をプールさせない くらいでした． どうするのがセオリーなのかと調べてみると コネクションプーリングの話 - naoyaのはてなダイアリー 2006-09-03 など4年近く前に議論されていて，"あー，高速道路あるなあ"と，コネクション確立のコストを調べる前に「プール
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Using ActiveRecord with EventMachine | Mike Perham
2010-03-30 eventmachine Given all my work with Fibers and EventMachine over the last three months, it should come as no surprise that I’ve been working on infrastructure based on Fibers and EventMachine to get maximum scalability without the callback style of code which I dislike for many reasons. Watch my talk on scaling with EventMachine if you need more background on the problem. Now that I hav
SinatraからActiveRecord 3を使う(1) マイグレーション - アインシュタインの電話番号
以前SinatraからDataMapperを使う記事を書いたけど、今回はSinatraのO/Rマッパー部分にActiveRecord 3を使ってみる。ActiveRecord 3自体の使い方については、この記事がすごくわかりやすかった。 Sinatraアプリに必要なファイルを用意する まずは、Sinatraアプリを実行するのに必要な最低限のファイル群(Gemfile, config.ru, app.rb)を作成する。今回は基本的にすべてBundler経由で操作するので、システム側にBundlerのgemがインストールされている必要がある。 Gemfile 今回使用するgemはこんな感じ。とりあえずSinatraでActiveRecord 3を使う場合はactiverecordとsinatra-activerecordとsqlite3が必要で、今回使ったバージョンはそれぞれ、3.0.6、0.
javascriptでActiveRecordっぽくハッシュを検索するコードの断片 - ニート=>ネトゲ屋=>ブラック=>電話屋
javascriptもrubyと同様にインスタンス*1に対して動的にフィールドを追加できるようだ。javascriptなのでバインドは名前を付けた関数でも可能である。 ということでActiveRecordみたいな手触りのものが作れる。 めっぽう簡単なコードで。 今のところ機能として絞り込み(and検索)にも対応しているが都度実処理してしまっているところを最終段階まで遅延させたいところ。 // コード var AR = { Init : function(hash){ //関数をバインド for(x in this) if(typeof this[x] == "function") hash[x] = this[x]; return hash; }, find :function(k) { //関数をバインド for(x in this) if(typeof this[x] == "func
WordPressのデータをActiveRecordでいじる - ひげろぐ
the_titleとかget_the_titleとかWordPressのネーミングセンスにつきあってると頭がおかしくなって死ぬ。 万事そんなかんじなので、可能であればなるべくおつきあいを遠慮したい。 WordPressのDBはMySQLなのでテーブルの構成さえ分かればActiveRecordなりSQLなりでデータを直接いじれる。 ということでバッチ処理等、フロントエンドに関係なくDBにだけタッチすればよい場合はWordPressとは独立したプログラムを書いて対応することができる。 ただしデータを直接いじる場合は、WordPressのフィルタ機構が働かない点に注意。 投稿の更新の際にフィルタをかけるプラグインなどを利用している場合は、データに不整合が出てしまう可能性もある。 WordPressのテーブル構造 Database Description « WordPress Codex バージ
ActiveAndroid | Active record style ORM for Android
Active record style ORM for AndroidMinimal Configuration Working with databases in Android can be a pain. With ActiveAndroid you can configure your project in just two easy steps! Learn More… Automagical Objects Why mess around with database setup? Create your classes and ActiveAndroid will create your database for you. It'll even handle relationships. Learn More…
Ruby on Rails: UUID as your ActiveRecord primary key · devroom.io
Sometimes, using the good old ‘auto increment’ from your database just isn’t good enough. If you really require that all your objects have unique ID, even across systems and different databases there’s only one way go: UUID or Universally Unique IDentifier. A UUID is generated in such a way that every generated UUID in the world is unique. For example: 12f186e6-687e-11ad-843e-001b632783f1. This st
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kamipo/activerecord-mysql-awesome: Awesome patches backported for ActiveRecord MySQL adapters.
MySQLとActiveRecord
Loading...