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が使えるとおもう。

ざざっとコードを読んだかぎり、とても筋がいいとおもう。センスがいいとも言う。