De meilleures fondations Voyez clairement votre client et assurez une mesure précise avec une identité fondamentale solide. Protégez la confiance avec les normes les plus élevées en matière de confidentialité et d'éthique des données. La vue client dont vous avez besoin Reliez les points de contact pour une compréhension plus profonde, plus riche et plus dynamique tout au long d'un parcours client
ActiveRecord-JDBC-Adapter (AR-JDBC) is the main database adapter for Rails' ActiveRecord component that can be used with JRuby. ActiveRecord-JDBC-Adapter provides full or nearly full support for: MySQL, PostgreSQL, SQLite3 and MSSQL* (SQLServer). Unless we get more contributions we will not be supporting more adapters. Note that the amount of work needed to get another adapter is not huge but the
Using the select parameter in Active Record association your can speed up you application about 50% and more. The following example is only focused on the optimization of the association using select, so there are further optimizations for the following examples. Given the models: class Patient < ActiveRecord::Base belongs_to :physician end class Physician < ActiveRecord::Base has_many :patients e
今更ですが、rails の has_many :through を使った データの多対多関係の扱いをまとめてみようかと。 (※ もう少し早く、もうちょっと理解してれば 今もう少し楽できたなという後悔を含め。) Tweet さて、今回使うのは単純なクラブと学生の紐付け。 クラブには複数人の学生が紐付けれるし、 学生にも複数のクラブを紐付けれる。 そんな関係。 で、"クラブ"テーブルと"学生"テーブルを作成する。 そんで、データはこんな感じで入れておく。 [クラブ] [学生] もう一つ、紐づけるためのテーブルが必要になる。 "クラブ"テーブルと"学生"テーブルの紐付けを行うんで、 "club_students" という名前でもして作成する。 "club_students" には、"クラブ"テーブルの id と "学生"テーブルの id をそれぞれ持たせる。 こんな感じ↓ で、これを rails
読んでいたコードで面白いテクニックを使っていたのでメモ。 Rails のActiveRecord のfind 系メソッドは優秀だと思うけど、自分でSQL を書きたい時があると思います。そこで、find_by_sql を使うわけですが、その際、大規模なSQL を書く場合のTips です。 環境 ruby 1.8.7 rails 2.2.2 パラメータによってSQL 自体を変えたい場合 例えば、SQL が以下だったとします。 RDBMS はSQLite3 SELECT * from users where name = xxx; これを扱う、find_by_sql が以下のような感じ。 User.find_by_sql(["select * from users where name = :name", {:name => 'bob'}]) #=> [#<User id: 1, name: "
Subject: [ruby-list:43356] TCPSocket#flushでスレッドが停止する現象について From: "KOSEKI Kengo" <kengo@ . m r p Date: Mon, 2 Apr 2007 18:20:17 +0900 はじめまして。 小関と申します。 Rails + MySQLを使っていて、長時間DBへのアクセスが無い場合に Railsアプリケーションが反応しなくなる問題を調べています。 MongrelのFAQでそれらしい現象が報告されているのですが、 http://mongrel.rubyforge.org/faq.html > Q: Mongrel stops working if it's left alone for a long time. ここに載っている対策は以下の点で正しくないのではないかと 考えています。 * ソースを読むと
(追記) この問題について、原因はRubyの側にあるのではないかと考えています。特定の条件下でTCPSocket#flushを実行すると、スレッドが停止したまま処理が戻ってこなくなります。以下の投稿で、Railsを使わず再現する方法を説明しました。 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/43356 (追記おわり) 開発サーバが翌日になるとデッドロックする、という現象が続いていて悩みました。 解決方法は、MongrelのFAQに上がっていました。 http://mongrel.rubyforge.org/faq.html Q: Mongrel stops working if it’s left alone for a long time. If you find that Mongrel stops work
カテゴリ: Ruby, トラブルシューティング Mongrel + MySQLという構成のRailsアプリを1日程度まったくアクセスせずに放置すると、Mongrelが刺さって動かなくなるという非常に困った現象が発生する。原因もその対処もさっぱり分らない謎すぎる現象だが、実はその筋では割とよく知られた話であるようだ。 Rails + MySQL (+ Mongrel?) でDB接続の通信が無い状態が続くとデッドロックする。 - こせきの技術日記 [ruby-list:43356] TCPSocket#flushでスレッドが停止する現象について 現象が発生するまでの時間がMySQLのwait_timeoutとKEEP_ALIVEなTCPソケットのTIME_WAIT期間が終わるまでの10時間もかかるため、なかなか再現しないイヤな問題である。MongrelのFAQにwait_timeoutととの関
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く