DBによる制約 (not null)
Sequel.migration do
up do
create_table :users do
primary_key :id
String :name, null: false
end
end
down do
drop_table :users
end
end
こんなかんじで users.name について not null 制約をかける。
Sequelによる制約
するとSequelが例外 (Sequel::InvalidValue) を投げる。
class User < Sequel::Model; end
User.new(name: nil) # -> Sequel::InvalidValue
対処
特にウェブ・アプリケーションなどでこの強い制約は扱いづらいので例外の発生を抑制する。
# RailsとかPadrinoだと config/database.rb あたりにでも
Sequel::Model.raise_on_typecast_failure = false
DBに施された制約 (この例だと not null 制約) は残ったままで、Sequel::Modelによる制約 (!= 検証) がなくなった状態になる。
検証 (validation, != 制約, constraint)
空文字列も含めた「空の値」ではないことを求めるよりリッチで柔軟な検証として validates_presence が使えるので、それを使う。
class User
def validate
validates_presence :name
end
end
User.new.valid? # -> false
余談
SequelはActiveRecordと比べてよりRDBに対してローレベルな操作ができる。(check制約などを付与するのも簡単)
それでいてバックエンド剥き出しではなくきちんと抽象化されている。 (Rubyへ落としこまれている)
ActiveRecordをはじめとするRailsプロダクトは規約を外れると使いづらさが極端に増すことでゆるやかな洗脳を仕掛けることで有名で、それはRubyに近いところがある。
それはそれでソフトウェア開発における啓蒙的アプローチとして妥当なのだけど、勧められるものを蹴ってまで規約を外れなきゃいけないケースは少なくないわけで、そういったケースのための一手として、たとえばSequelが使えるとおもう。
ざざっとコードを読んだかぎり、とても筋がいいとおもう。センスがいいとも言う。