effective_end_dateと列が実際に日付である場合、日付の最小解像度は1日であり、900秒は86400秒(別名または1日)effective_start_dateよりもかなり小さいため、クエリは無意味です。25*60*60したがって、「日付」列は実際には日時(別名タイムスタンプ)列であると想定します。これが当てはまる場合は、メンテナンス中の混乱を避けるために列の名前を変更することをお勧めします。これはeffectively_starts_at、effectively_ends_at通常のRailsの規則によく一致します。この仮定が無効な場合は、列タイプを変更するか、900の使用を停止する必要があります。
本当の問題に戻りましょう。ActiveRecord::ConnectionAdapters::Quoting#quoteActiveRecordは、次の方法を使用してRuby値をSQL値に変換します。
def quote(value, column = nil)
# records are quoted as their primary key
return value.quoted_id if value.respond_to?(:quoted_id)
case value
#...
else
"'#{quote_string(YAML.dump(value))}'"
end
end
したがって、プレースホルダーの値として何かを使用しようとし、そのタイプに特定の処理が組み込まれていない場合は、YAML(デフォルトのIMOの奇妙な選択)が得られます。また、900.secondsはActiveSupport::Durationオブジェクトであり(何を900.seconds.class言っているかにかかわらず)、そのためcase valueのブランチがないためActiveSupport::Duration、900.secondsYAML化されます。
PostgreSQLアダプタは独自のquoteを提供しますActiveRecord::ConnectionAdapters::PostgreSQLAdapter#quoteが、それはどちらも知りませんActiveSupport::Duration。MySQLアダプタquoteも。を認識していませんActiveSupport::Duration。quoteこれらのメソッドにモンキーパッチを適用することができます。イニシャライザでこのようなもの:
class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter
# Grab an alias for the standard quote method
alias :std_quote :quote
# Bludgeon some sense into things
def quote(value, column = nil)
return "interval '#{value.to_i} seconds'" if(value.is_a?(ActiveSupport::Duration))
std_quote(value, column)
end
end
ActiveSupport::Durationそのパッチを適用すると、 :を使用したときにPostgreSQLが理解できる間隔が得られます。
> Model.where('a - b > ?', 900.seconds).to_sql
=> "SELECT \"models\".* FROM \"models\" WHERE (a - b > interval '900 seconds')"
> Model.where('a - b > ?', 11.days).to_sql
=> "SELECT \"models\".* FROM \"models\" WHERE (a - b > interval '950400 seconds')"
同様のパッチをMySQLアダプタquote(読者の演習として残されています)に追加すると、次のようになります。
UserRole.where("(effective_end_date - effective_start_date) > ?", 900.seconds)
PostgreSQLとMySQLの両方で正しいことを実行し、コードはそれについて心配する必要はありません。
とは言うものの、さまざまなデータベースで開発して展開することは、サンタクロースを泣かせて、貯蔵用の石炭(おそらくヒ素が混入している可能性があります)を探しに行くという非常に悪い考えです。だからそうしないでください。
一方、データベースにとらわれないソフトウェアを構築しようとしている場合は、楽しい時間を過ごすことができます。データベースの移植性は主に神話であり、データベースにとらわれないソフトウェアとは、プラットフォームが提供するORMおよびデータベースインターフェイスの上に独自の移植性レイヤーを作成することを常に意味します。サポートする予定の各データベースですべてを徹底的にテストする必要があります。誰もがSQL標準にリップサービスを支払いますが、誰もそれを完全にサポートしていないようで、誰もが心配する独自の拡張機能と癖を持っています。ユーティリティメソッドとモンキーパッチを組み合わせた独自のポータビリティレイヤーを作成することになります。