2015/03/17分のコミットです。 CHANGELOGにのったコミットは以下の通りです。 activerecord/CHANGELOG.md Closes rails/rails#18864: Renaming transactional fixtures to transactional tests Adds an example of how to access the arguments passed to a custom rake task [ci skip] rails guideのThe Rails Command Lineの修正です。 Custom Rake Tasksに記載されているcustom rake taskのexampleに、引数にアクセスする方法について記載したコードを追加しています。 Materialize subqueries by adding DIS
訳あって、Ruby on RailsでMySQLに画像を格納し使う実験をした。 migrationでの指定 画像を格納するカラムは migration では binary を指定します。ただし、そのままでは 64Kbyteまでしか格納出来ない blob型になってしまいます。これを mediumblob型にするには、 migrationファイルで :limit => (16*1024*1024 - 1) を指定します。 def self.up create_table :table_name do |t| t.binary :column_name, :limit => (16*1024*1024 - 1) t.timestamps end endネットを検索すると、mediumblob指定の為に execute でMySQLのSQL文を書くような記事が見つかりますが、そんな面倒はいりません
ActiveRecordを使ったRailsアプリは,デフォルトでデータベースへの接続をプールするようになっています. ActiveRecordユーザとしては待ちわびたぜ!的な機能らしいのですが,設定等でこれをdisableすることが出来ず,LVS+keepalivedを介する場合にはロードバランシングが最初の接続時にしか為されずがなかなか厄介です. 対策として思いついたのは プールした接続を早い周期で捨てる LVS+keepalivedではなく,MySQL Proxyでバランシングする(Proxyへの接続はプール) そもそも接続をプールさせない くらいでした. どうするのがセオリーなのかと調べてみると コネクションプーリングの話 - naoyaのはてなダイアリー 2006-09-03 など4年近く前に議論されていて,"あー,高速道路あるなあ"と,コネクション確立のコストを調べる前に「プール
Railsは度々遅いということが話題に上がる。Ruby自体の性能もあるだろうが、データベースを富豪的に使っているのにも原因がある。便利であるためについついデータベースを多用していたり、データの取り出しを複雑(都度集計など)にしていないだろうか。 メイン画面 個人的な経験から言えばボトルネックになりがちなのはレンダリングとデータベースだ。このデータベースの問題点を洗い出すのに便利なのが、またしてもRailsアプリケーションだ。 今回紹介するフリーウェアはPalmist、RailsのMySQL実行履歴を見るソフトウェアだ。ソースはGithubで公開されているがライセンスは明記されていなかったので注意していただきたい。 Palmistは他のRailsアプリケーションのログファイルを読み取って、それを解析して表示してくれる。コントローラ、アクション、DBへのCRUDごとにリストアップしてくれる。実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く