# Rails 1.1: not-null constraint violations **URL:** \ **Category:** Rails\ **Created:** [March 28, 2006, 11:21pm UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529 "2006-03-28T23:21:34Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 28, 2006, 11:21pm UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/1 "2006-03-28T23:21:34Z")
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 ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 12:59am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/2 "2006-03-29T00:59:34Z")
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 ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 7:22am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/3 "2006-03-29T07:22:57Z")
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. ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 8:45am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/4 "2006-03-29T08:45:37Z")
If you can compare the sql statement generated with 1.0 vs 1.1 and confirm if that is the difference. ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 8:17am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/5 "2006-03-29T08:17:26Z")
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 ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 8:51am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/6 "2006-03-29T08:51:15Z")
this particular problem with now() default values is result of [http://dev.rubyonrails.org/changeset/3913](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. ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 8:45am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/7 "2006-03-29T08:45:38Z")
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/changeset/3913) [http://dev.rubyonrails.org/ticket/2257](http://dev.rubyonrails.org/ticket/2257) Joe ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 9:09am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/8 "2006-03-29T09:09:12Z")
Well, I define defaults in DB and just type: new\_record = MyModel.new\_default ( see [http://dev.rubyonrails.org/ticket/2259/](http://dev.rubyonrails.org/ticket/2259/) ) ---
**Author:** ![joe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b9e5f3/32.png) [@joe](https://www.ruby-forum.com/u/joe)\ **Post date:** [March 29, 2006, 9:04am UTC](https://www.ruby-forum.com/t/rails-1-1-not-null-constraint-violations/89529/9 "2006-03-29T09:04:25Z")
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](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