Rails is wrong in its coercion of empty dates to nil and requiring a table field to allow NULL as the only alternative to a valid date entry. NULL = unknown, unavailable, "still waiting" etc. It''s a well established discussion that NULL is needed to allow that third option to zero and non-zero, empty and non-empty. Rails is wrong in insisting that logic does not extend to dates. A valid date = an affirmative akin a non-empty string, a non-zero number. A 0000-00-00 is an affirmative akin to an empty string, or a zero. NULL is the _third_ option. A valid date says an event happened. A NULL says we''re still waiting for confirmation that the event happened. A 0000-00-00 says that the event did not happen, never will happen. It is not "unknown." It is not "unavailable." Rails is wrong in asserting that 0000-00-00 is poor database design, and Rails is wrong to prevent the value from being used. -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Rails is wrong in asserting that 0000-00-00 is poor database design, and > Rails is wrong to prevent the value from being used.Your approach is wrong in attempting to generate discussion. Your attempt to make your point clear is wrong in that I don''t follow what it is you''re trying to achieve. I''m not sure what problem you''ve hit, what solution you propose, or how you want to implement it, but I do know you think rails is wrong? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Koziarski wrote:>> Rails is wrong in asserting that 0000-00-00 is poor database design, and >> Rails is wrong to prevent the value from being used. > > Your approach is wrong in attempting to generate discussion. Your > attempt to make your point clear is wrong in that I don''t follow what > it is you''re trying to achieve. > > I''m not sure what problem you''ve hit, what solution you propose, or > how you want to implement it, but I do know you think rails is wrong?Yeah, you''re right, I Ieft too many "Rails is wrong" in there. I wrote each one planning for that to be the one after I got done editing, and I got interrupted and sent the message thinking I was done. It reads flamey for sure. My appologies. Anyway... If a (MySQL) database table declares a datetime field as NOT NULL with a default value of 0000-00-00 00:00:00 and an empty value is submitted to that field via Rails, Rails complains that the field cannot be null. If a string literal of 0000-00-00 00:00:00 is submitted, Rails coerces the value to nil, and once again complains about not null. I tracked down some bug reports and other posts, and it appears that the Rails core position is that using 0000-00-00 is poor data design, and it is Rails'' duty to not allow it to be used, further taking the position that that''s what NULL is for. Well, NULL is for that third alternative. As it stands, Rails allows only two states for dates. A valid date or NULL. There are occassions, rare as they may be, to interpret date data in three ways just like numerics or strings. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Greg Willits wrote:> Michael Koziarski wrote:>> I don''t follow what it is you''re trying to achieve.Dang. Did it again. You wanted scenarios... A typical example would be a Date Due field where a valid date = when it was done, a NULL value = not done yet that we know of, and a 0000-00-00 value = it has been declared that it never will be done. Reports for this data must be able to distinguish between all three casees. Additionally, I have legacy data/logic being replicated in Rails that expects to find and handle 0000-00-00 date values a specific way. AFAICT I have no way to continue the legacy data/logic systems using Rails as I cannot populate a date field with 0000-00-00 to remain consistent with existing data. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> >> I don''t follow what it is you''re trying to achieve. > > Dang. Did it again. You wanted scenarios...No worries, sorry if I came across a little harsh. If you can find the trac tickets where this has been discussed and perhaps when it was first introduced we could figure out what was going on. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
A date field should contain only valid dates or be null. If you need a third alternative, use a code/switch field or store your date in a string. I don''t believe there are any valid scenarios where storing invalid dates in a date field is more appropriate than using a separate code/switch to indicate the additional context. On Nov 24, 2007, at 10:45 PM, Greg Willits wrote: ... snipped parts of prior included posts> > Well, NULL is for that third alternative. As it stands, Rails allows > only two states for dates. A valid date or NULL. There are occassions, > rare as they may be, to interpret date data in three ways just like > numerics or strings. > > -- gw >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 24, 8:53 pm, Greg Willits <ruby-forum-incom...@andreas-s.net> wrote:> A typical example would be a Date Due field where a valid date = when it > was done, a NULL value = not done yet that we know of, and a 0000-00-00 > value = it has been declared that it never will be done. Reports for > this data must be able to distinguish between all three casees.Ugly Hax and total abuse of a magic value, imo. Use a flag, as per Josh''s post.> Additionally, I have legacy data/logic being replicated in Rails that > expects to find and handle 0000-00-00 date values a specific way. AFAICT > I have no way to continue the legacy data/logic systems using Rails as I > cannot populate a date field with 0000-00-00 to remain consistent with > existing data.I don''t think rails should be designed to play nicely with your invalid legacy data, personally. Designing the framework around individual cases of legacy usage is a very, very bad idea. Anyways, I can imagine core members responses already, once they figure out what you are asking: "Sounds like a great idea for a plug-in." ;) --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Tim Connor wrote:> On Nov 24, 8:53 pm, Greg Willits <ruby-forum-incom...@andreas-s.net> > wrote: >> A typical example would be a Date Due field where a valid date = when it >> was done, a NULL value = not done yet that we know of, and a 0000-00-00 >> value = it has been declared that it never will be done. Reports for >> this data must be able to distinguish between all three casees. > > Ugly Hax and total abuse of a magic value, imo. Use a flag, as per > Josh''s post.Just because I''ve seen it, doesn''t mean it''s "right" (and v.v.) but I''ve seen it often enough. Database providers allow the value as legal, so why shouldn''t it be used? Nothing magic about it IMO. Most date parsing and validating code I''ve ever seen accepts it or uses it in some way (not that I''ve seen everything). It is logical and it avoids the need of exactly the type of field you''re proposing (which of course is the typical alternative).>> Additionally, I have legacy data/logic being replicated in Rails that >> expects to find and handle 0000-00-00 date values a specific way. AFAICT >> I have no way to continue the legacy data/logic systems using Rails as I >> cannot populate a date field with 0000-00-00 to remain consistent with >> existing data. > > I don''t think rails should be designed to play nicely with your > invalid legacy data, personally.Well, there''s the difference I guess. I don''t see it as an invalid date -- when databases allow/require it as the value in a non-null date field, I see it is as being valid as a "non-date" or "zero date."> Designing the framework around > individual cases of legacy usage is a very, very bad idea. Anyways, I > can imagine core members responses already, once they figure out what > you are asking: "Sounds like a great idea for a plug-in." ;)And if I can be pointed to how/where to override this behavior I would be happy -- I''ve started to dig into Rails internals, but just barely, and still trying to push my way through the multple layers of abstractions for things. I''ve downloaded the acts_as_monkey outline for plugins, but haven''t experimented yet. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Koziarski wrote:>> >> I don''t follow what it is you''re trying to achieve. >> >> Dang. Did it again. You wanted scenarios... > > No worries, sorry if I came across a little harsh.Nah, I started it ;-)> If you can find the trac tickets where this has been discussed and > perhaps when it was first introduced we could figure out what was > going on.http://dev.rubyonrails.org/ticket/2391 If the answer is that this particular group of people have a binary view of dates, then waddya gonna do? 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. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> > If you can find the trac tickets where this has been discussed and > > perhaps when it was first introduced we could figure out what was > > going on. > > > http://dev.rubyonrails.org/ticket/2391 > > If the answer is that this particular group of people have a binary view > of dates, then waddya gonna do? > > 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. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Do we want to follow MYSQL, or any specific DB provider, practices, over ruby''s, though? And/or the standards? (Don''t honestly know what ANSI SQL has to say about 0000-00-00). --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Tim Connor wrote:> Do we want to follow MYSQL, or any specific DB provider, practices, > over ruby''s, though? And/or the standards? (Don''t honestly know what > ANSI SQL has to say about 0000-00-00).Isn''t that one of the reasons for choosing one database over another--its support of different functionalities? What''s the point of having different dbs if app frameworks reduce them to some wimpy lowest common denominator. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> What''s the point of having different dbs if app frameworks reduce them > to some wimpy lowest common denominator.Why even bother with SQL, then :)? Why not just give every database their own query language that''s designed just for them. There are other reasons than API to pick different databases (like performance, storage engines, replication facilities, etc). --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
DHH wrote:>> What''s the point of having different dbs if app frameworks reduce them >> to some wimpy lowest common denominator. > > Why even bother with SQL, then :)? Why not just give every database > their own query language that''s designed just for them. There are > other reasons than API to pick different databases (like performance, > storage engines, replication facilities, etc).ok, well, that fork is headed nowhere, but I still don''t see what the heck the catastrophe is behind allowing the database to accept defaults it deems as valid, even resorts to, in its own API. -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 24, 2007 10:45 PM, Greg Willits <ruby-forum-incoming@andreas-s.net> wrote:> If a (MySQL) database table declares a datetime field as NOT NULL with a > default value of 0000-00-00 00:00:00 and an empty value is submitted to > that field via Rails, Rails complains that the field cannot be null. If > a string literal of 0000-00-00 00:00:00 is submitted, Rails coerces the > value to nil, and once again complains about not null. >This is the biggest issue for me - the coercion. How "agnostic" is Rails attempting to be if it''s actively overriding or erroring on what the selected DB allows for values? --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
The 1992 draft SQL standard (sorry, all I have handy at the moment) says "The <datetime field>s other than SECOND contain non-negative integer values, constrained by the natural rules for dates using the Gregorian calendar." This leaves it up to the Gregorian calendar, which doesn''t have a year zero, much less month zero and day zero as far as I can tell. The ISO 8601 standard allows zero and negative year values to represent BC dates, but still requires non-zero month and day values. I''ve been mostly a DB2 user for 20 years or so, but I believe that most RDBMS implementations follow the standard and disallow 0000-00-00 as an invalid date. On Nov 26, 2007, at 3:30 PM, Tim Connor wrote:> > Do we want to follow MYSQL, or any specific DB provider, practices, > over ruby''s, though? And/or the standards? (Don''t honestly know what > ANSI SQL has to say about 0000-00-00). > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
John Maenpaa wrote:> The 1992 draft SQL standard (sorry, all I have handy at the moment) > says "The <datetime field>s other than SECOND contain non-negative > integer values, constrained by the natural rules for dates using the > Gregorian calendar." This leaves it up to the Gregorian calendar, > which doesn''t have a year zero, much less month zero and day zero as > far as I can tell. The ISO 8601 standard allows zero and negative year > values to represent BC dates, but still requires non-zero month and > day values. I''ve been mostly a DB2 user for 20 years or so, but I > believe that most RDBMS implementations follow the standard and > disallow 0000-00-00 as an invalid date.I would argue this is not an issue of "most" or even "standard" -- most code on the planet is probably written with camelCase names -- which doesn''t seem to have much impact on Rails'' opinion. This is a simple case of having the database adaptor allow what the database itself considers legal. Not only legal, but Rails is preventing the db from using its own default behavior. It doesn''t matter if the DB2, Oracle or Sybase worlds think its dumb. Its an adaptor for MySQL. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
BTW everyone -- I appreciate the discussion, and the points being made. Not convinced I''m wrong yet, but I do appreciate the time being taken to read & respond. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> I would argue this is not an issue of "most" or even "standard" -- most > code on the planet is probably written with camelCase names -- which > doesn''t seem to have much impact on Rails'' opinion.The real problem is that you *can''t* retrieve that data again. Rails needs to coerce those values into a Date or Time, neither of which accept 0000-00-00. So we can''t support it when reading data, there''s not much point letting you write it. After all, you can''t construct the time object to save in the first place. Given that ruby can''t support that value, coercing to nil seems at least reasonable.> This is a simple case of having the database adaptor allow what the > database itself considers legal. Not only legal, but Rails is preventing > the db from using its own default behavior. It doesn''t matter if the > DB2, Oracle or Sybase worlds think its dumb. Its an adaptor for MySQL. > > -- gw > -- > Posted via http://www.ruby-forum.com/. > > > >-- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Michael Koziarski wrote:>> I would argue this is not an issue of "most" or even "standard" -- most >> code on the planet is probably written with camelCase names -- which >> doesn''t seem to have much impact on Rails'' opinion. > > The real problem is that you *can''t* retrieve that data again. Rails > needs to coerce those values into a Date or Time, neither of which > accept 0000-00-00. So we can''t support it when reading data, there''s > not much point letting you write it. After all, you can''t construct > the time object to save in the first place. > > Given that ruby can''t support that value, coercing to nil seems at > least reasonable.Hmm. That doesn''t negate the ability to at least conduct searches based on what the db can contain, but it''s a valid point in that it makes implementing full support for it difficult. OK, well, that settles that. I''ll drop it. From an app code perspective, one way around this inability is to use varchar for dates (in the ISO format). I''ve done that before too in a few cases where a variety pf reasons made using varchars for dates easier to work with (casting on demand when needed for calculations). It''s nice to not have to do that, but it works. Anyway, thanks for listening. -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 26, 2007, at 9:40 PM, Michael Koziarski wrote:>> I would argue this is not an issue of "most" or even "standard" -- >> most >> code on the planet is probably written with camelCase names -- which >> doesn''t seem to have much impact on Rails'' opinion. > > The real problem is that you *can''t* retrieve that data again. Rails > needs to coerce those values into a Date or Time, neither of which > accept 0000-00-00. So we can''t support it when reading data, there''s > not much point letting you write it. After all, you can''t construct > the time object to save in the first place.What about 0? Then the OP could test with .zero? -- Jordi
Jordi Bunster wrote:> On Nov 26, 2007, at 9:40 PM, Michael Koziarski wrote: > >>> I would argue this is not an issue of "most" or even "standard" -- >>> most >>> code on the planet is probably written with camelCase names -- which >>> doesn''t seem to have much impact on Rails'' opinion. >> >> The real problem is that you *can''t* retrieve that data again. Rails >> needs to coerce those values into a Date or Time, neither of which >> accept 0000-00-00. So we can''t support it when reading data, there''s >> not much point letting you write it. After all, you can''t construct >> the time object to save in the first place. > > What about 0? Then the OP could test with .zero?What''s "OP" ? I think Koz''s point is that with Rails doing auto-type-casting upon reading the data, it''s going to take anything that Ruby rejects and convert it to nil. We could push the issue further by asking the rejected value be cast into a string so at least we get the value actually in the database, but I see even stronger resistanec to that as it would then require the app code to check for three possible object classes (Date, String, Nil) instead of two (Date, Nil) -- since most of these guy apparently don''t see value in 0000-00-00 to start with, I think that''s a losing proposition. So, whether its 0 or 0000-00-00 doesn''t really matter, it''s an added condition born out of distrusting the data type (err, Class) of an object. Nobody''s going to care for that much. I''d still be curious about where in Rails, one could tap in to override the default behavior (for some legacy needs), but I can see them not adding it to core because of the native behavior of Ruby. In my past work, the native language could tell the difference, so the whole 0000-00-00 could be supported across the board as a valid third representation for dates. If Ruby isn''t going to offer that, then Rails has to do a lot of work to get around it (and it''s obvious that there''s not a lot of motivation for them to do that). If an app really has to have this, like some of my legacy stuff does, the easiest way to get there is to use varchars for dates, add the three-class testing in the app code, and handle the type casting in the app models. It''s a bummer, but it can be done. (hmm, if I were a politician I''d be accused of flip-flopping right about now, but hey, when the writing is on the wall...) -- gw -- 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---