On Sep 2, 9:45 pm, Dave Howell <[email protected]> wrote: > Sequel and I aren't agreeing as to what constitutes validity. > > create table datathings ( > id uuid DEFAULT uuid_generate_v1() NOT NULL, > singing varchar not null, > dancing varchar, > primary key (id) > ) > > class Datathing < < Sequel::Model > end > > >> d = Datathing.new > => #< Datathing @values={}> > >> d.save > Sequel::DatabaseError: PGError: ERROR: null value in column "singing" > violates not-null constraint > >> d.valid? > => true > > I'm sorry, but "true" is not the correct answer. I started to try to find a > way for Sequel to learn what the database's constraints were, but I > discovered that it already knows them. > > >> d.singing = "Girls Just Want To Have Fun" > => "Girls Just Want To Have Fun" > >> d > => #< Datathing @values={:singing=>"Girls Just Want To Have Fun"}> > >>d.singing = nil > Sequel::InvalidValue: nil/NULL is not allowed for the singing column > > So if Sequel already *knows* that singing cannot be null, why would .valid? > return 'true' when I first created a new Datathing object and singing hadn't > been initialized yet??
Perhaps because you do not have a validation that covers that case? I have never used Sequel validations so feel free to correct me but based on what is documented here http://sequel.rubyforge.org/rdoc/files/doc/validations_rdoc.html it seems to me that Sequel is behaving as advertised. Validations are a layer above DB constraints and do not subsume them. Sequel does not know (but it could) that the singing column cannot be null, the database does and the error that is reported is from the database, not Sequel. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
