So I have a database of orders more or less.(it is currently in the process of being upgraded to mysql with a rails fronted, from OLD Paradox database) On one page I made a ''create new order'' system. This allows me to put in the due date and other info. However I wanted to put in the default value of ''0000-00-00'' for the shipped date, as it hasn''t shipped yet. Only Ruby won''t let me do that, it calls that value ''null'' and balks saying "Mysql::Error: Column ''Ship_Date'' cannot be null..." It is probably something obvious I am just overlooking. But Its been one of those fridays and my mind is gone. So any help would be greatly appreciated. -- Posted via http://www.ruby-forum.com/.
Hey Chris, I ran into a similar problem with some legacy db tables and posted a message on this list. The only answer I got was "thats bad db design" which isn''t that helpful. You may be able to setup a "before_save" callback to insert the default value manually or alter the table to allow nulls. Hope that helps! Tim On Aug 18, 2006, at 11:30 AM, Chris Edie wrote:> So I have a database of orders more or less.(it is currently in the > process of being upgraded to mysql with a rails fronted, from OLD > Paradox database) On one page I made a ''create new order'' system. > This > allows me to put in the due date and other info. However I wanted > to put > in the default value of ''0000-00-00'' for the shipped date, as it > hasn''t > shipped yet. Only Ruby won''t let me do that, it calls that value > ''null'' > and balks saying > "Mysql::Error: Column ''Ship_Date'' cannot be null..." > It is probably something obvious I am just overlooking. But Its > been one > of those fridays and my mind is gone. So any help would be greatly > appreciated. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Friday 18 August 2006 19:30, Chris Edie wrote:> So I have a database of orders more or less.(it is currently in the > process of being upgraded to mysql with a rails fronted, from OLD > Paradox database) On one page I made a ''create new order'' system. This > allows me to put in the due date and other info. However I wanted to put > in the default value of ''0000-00-00'' for the shipped date, as it hasn''t > shipped yet. Only Ruby won''t let me do that, it calls that value ''null'' > and balks saying > "Mysql::Error: Column ''Ship_Date'' cannot be null..." > It is probably something obvious I am just overlooking. But Its been one > of those fridays and my mind is gone. So any help would be greatly > appreciated.Chris, Since the Ship Date can be null (i.e. it will have an unknown value), then you need to define the column in the table to be nullable. If you are using migrations the default behaviour is to make a column nullable (to make it "not null" you need to specify :null => false). So I''m assuming you''ve created the database using SQL directly. Take the "NOT NULL" off the definition from that column. You should never use default dates like 0000-00-00 or 9999-01-01 to signify an unknown date : this is what the null option on a database is there for. HTH Phil
An amazingly simple solution... GAH! ... really part of the problem with trying to bring a 15year old piece of software up to date, is I get myself caught in trying to keep it as similar as possible, while makeing the necessary changes. I did go ahead and change the default values of the ship date to null. That seems to have worked well. I will have to go back in and edit some of the ''reporting'' software that shows what hasn''t shipped yet to search for NULL instead of 0000-00-00 But hey. We are getting somewhere! Thanks you two for your help. -Chris -- Posted via http://www.ruby-forum.com/.
On 8/18/06, Tim McIntyre <tmac@easystreet.com> wrote:> Hey Chris, > > I ran into a similar problem with some legacy db tables and posted a > message on this list. The only answer I got was "thats bad db > design" which isn''t that helpful. You may be able to setup a > "before_save" callback to insert the default value manually or alter > the table to allow nulls.The problem with this particular issue is that most consider that behavior broken, not just bad design. If end users come up with a workarround instead of fixing the underlying issue that''s fine, but it should not be in rails core.