Forum: Ruby on Rails Rails 1.1: not-null constraint violations

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Joe (Guest)
on 2006-03-29 01:21
Since upgrading to Rails 1.1, I now get these errors:

PGError: ERROR:  null value in column "added" violates not-null
constraint
: INSERT INTO authors ("added", ...) VALUES(NULL, ...)

The 'added' column has a default of current_timestamp, and this used to
work fine with Rails 1.0. Are we supposed to put default values in
models' before_create or something now?

Joe
Joe (Guest)
on 2006-03-29 02:59
Man, this is REALLY bad...mass breakage all over the place. Why doesn't
Rails automatically use the default values in the database? Grr...

Joe
Jim M. (Guest)
on 2006-03-29 09:22
(Received via mailing list)
I just ran into this a few days ago, and it had nothing to do with 1.1.

It appears that even if you have a default value set in the schema,
pgsql will give this error if you explicitly set a column to NULL (as in
your SQL INSERT below) on a non null column constraint.

The default appears to only be used if you do not specify a value in an
insert or update.

What may have changed in 1.1 is a create statement is now explicitly
setting null on a value that has no input value, rather than leaving it
out of the sql statement.

I do not know what the fix is but let me know if you discover any more.
My fix in my case was to add the columns in the form so they got
specified in the update or create.
Joe (Guest)
on 2006-03-29 10:17
Jim M. wrote:
>
> What may have changed in 1.1 is a create statement is now explicitly
> setting null on a value that has no input value, rather than leaving it
> out of the sql statement.

That's what it seems to be doing. And if it is, that's lame. I wasn't
explicitly specifying 'added=NULL'. I put 'self.added = Time.now() if
(self.added.nil? or self.added.empty?)' in before_create to get it to
work again. For columns like this, perhaps we're supposed to use
'created_at' - but what about other columns that Rails doesn't
automatically update and we want to rely on defaults in the database?
Either way, I've got a TON of minor code changes to do. Not happy.

Joe
Jim M. (Guest)
on 2006-03-29 10:45
(Received via mailing list)
If you can compare the sql statement generated with 1.0 vs 1.1 and
confirm if that is the difference.
Joe (Guest)
on 2006-03-29 10:45
I guess perhaps this is the reason:

Remove broken attempts at handling columns with a default of â??now()â?? in
the postgresql adapter. 2257 [Koz]

http://dev.rubyonrails.org/changeset/3913
http://dev.rubyonrails.org/ticket/2257

Joe
Lugovoi N. (Guest)
on 2006-03-29 10:51
(Received via mailing list)
this particular problem with now() default values is result of
http://dev.rubyonrails.org/changeset/3913

maybe ActiveRecord should on INSERT of new record just  omit NULL
values? So newly inserted record will be stored in database with all
needed defaults, defined in schema, but they won't be visible until
that record will be fetched back from database.
Joe (Guest)
on 2006-03-29 11:04
Lugovoi N. wrote:
>
> maybe ActiveRecord should on INSERT of new record just  omit NULL
> values? So newly inserted record will be stored in database with all
> needed defaults, defined in schema, but they won't be visible until
> that record will be fetched back from database.

Yeah...a newly created record would need to be retrieved right after
insertion. I guess this gets into the application vs. integration
database debate (http://www.loudthinking.com/arc/000516.html). It
appears the choices are to either use 'created_at/on' fields, or set the
values directly in ruby.

Joe
Lugovoi N. (Guest)
on 2006-03-29 11:09
(Received via mailing list)
Well, I define defaults in DB and just type:
 new_record = MyModel.new_default

( see http://dev.rubyonrails.org/ticket/2259/  )
This topic is locked and can not be replied to.