ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
Rails-4.2+MySQL-5.6での時刻オブジェクトのミリ秒の扱いについて - Qiita
MySQLは5.6系から時刻系のデータ型がミリ秒を持てるようになった。 やっとかよって感じですが。 最近持てるようになったので、Railsでは4.1まではMySQLに対してクエリを投げる時はミリ秒以下は問答無用で切り捨ててクエリを構築していた。 しかし、4.2betaが出る辺りで、MySQLにミリ秒対応のクエリを送るPRがマージされた。 MySQL 5.6 Fractional Seconds by arthurnn · Pull Request #14359 · rails/rails 既にMySQL側のカラムがミリ秒精度を持っている場合は特に問題は起きない。 けど、RailsでMySQL使っててRailsのバージョン上げようかって時に、そんなことはほぼ無いだろうと思う。 その場合、ちょっと面倒なことになる。 MySQL5.6がミリ秒以下の値を受け取った場合、精度が足りない部分は四捨五入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Add bigint primary key support for MySQL. by kamipo · Pull Request #18220 · rails/rails
金髪の神エンジニア・kamipo 伝説のもうひとつの真実 －トレジャーデータ 上薗竜太氏 - Forkwell Press
知って得しない Active Record Issues (MySQL編)
Allow precision option for MySQL datetimes by kamipo · Pull Request #17673 · rails/rails
「この境地にいるのは自分だけ」− 自身を追い込み続けてたどり着く「高み」とは − トレジャーデータ kamipo 氏 - Forkwell Press
Active Record Issues
