Michael Koziarski wrote: >> If I can override the behavior somehow, that would be fine with me too. >> I can design around it in the future, but I would like the option if >> it's possible. > > Unfortunately even if we did want to fix this, I'm not sure what the > accessors could return: > >>> Date.civil(0,0,0) > ArgumentError: invalid date > from > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/date.rb:727:in > `civil' > from (irb):9 >>> Date.ordinal(0,0) > ArgumentError: invalid date > from > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/date.rb:707:in > `ordinal' > from (irb):10 >>> > > > Ruby's date libraries are having none of that.
Well, the target is MySQL and not Ruby, so I am approaching this from the perspective of how to get what I want into MySQL, an not so much from what Rails or Ruby would natively prefer to do. If we skip Rails/Ruby altogether and work directly with MySQL, then here's what we discover (and is the source of my working with 0000-00-00 formatted empty dates): (these tables below are probably going to get mangled by this email system that's bent on hard wrapping short lines) CREATE TABLE `time_tests` ( `id` int(11) NOT NULL auto_increment, `null_date` datetime NULL default NULL, `zero_date` datetime NOT NULL default '0000-00-00 00:00:00', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; +-----------+----------+------+-----+---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------+----------+------+-----+---------------------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | null_date | datetime | YES | | NULL | | | zero_date | datetime | NO | | 0000-00-00 00:00:00 | | +-----------+----------+------+-----+---------------------+----------------+ insert into time_tests set zero_date='', null_date=''; insert into time_tests set zero_date='', null_date=null; +----+---------------------+---------------------+ | id | null_date | zero_date | +----+---------------------+---------------------+ | 1 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | | 2 | NULL | 0000-00-00 00:00:00 | +----+---------------------+---------------------+ When an empty string is submitted to MySQL, it defaults to 0000-00-00 even when the column default is NULL. In order to get a NULL value into MySQL, an explicit NULL value must be part of the query. Right now it appears Rails insists on submitting NULL to MySQL whenever Rails (perhaps Ruby) doesn't recognize a date as valid to its own inclinations. However, this is ignoring native MySQL behavior, and can be rectified by Rails' own philosophy of using reflection. It seems to me that Rails should be able to determine the DEFAULT value of the table definition and submit that default in queries. If the DEFAULT value for a date field is NULL, then Rails can submit NULL, but if a default value is not NULL, then it should send that default value--cast as a string if necessary to get around Ruby's inability to work with 0000-00-00 as a date object. So, the patch would have to be that Rails has a choice to send either NULL or whatever the default string is in the table definition. This way, a) native MySQL behavior is supported (which is the purpose of a db-specific adaptor) b) people that think date fields should be null or nn actual calendar date get the validations they want, and c) the people that want to work with 0000-00-00 can also get what they want. I would think that this tweak wouldn't be very difficult, but I have no idea where in Rails to monkey with that to supply you with a code sample. -- greg willits -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
