On Sep 7, 2010, at 9:20 AM, Andrew Hutchings wrote: > On 07/09/10 15:09, Tim Soderstrom wrote: >> On Sep 6, 2010, at 12:22 PM, Patrick Crews wrote: >> >>> At first glance, this looks really good to me. >>> >>> The only thing that makes my spider-sense tingle is this: >>> any date data containing 0000-00-00 -> 0001-01-01 >>> >>> I agree we need a conversion, but what if the table also contains date data >>> with '0001-01-01' (Who can say what depraved use of special dates exist out >>> there?) ; ) >>> >>> Of course, we can document this heavily so people will know what to expect >>> and can adapt as they see fit. It seems nicer than trying to think too much >>> for the user. >> >> I dunno how I feel about that one. Would it not be possible to convert >> 0000-00-00 to NULL? As both describe a date which is, in reality, undefined? > > We could do this too and set the column default to NULL. But this could break > some application in the same way since it will not be 0000-00-00 returned any > more. So I guess the question is which is the worst of 2 evils ;)
True but that's not a bad thing and, really, should be expected when moving to Drizzle due to the differences to MySQL. I like NULL here over a date since that's the way it probably should have been in the first place. It would be a dangerous evil for Drizzle to try and support poorly written applications. For those that cannot modify the application, they should simply continue to use MySQL is my thought. The reason Drizzle is not allowing 0000-00-00 is because it's an invalid date. Using 0001-01-01 is not invalid, but not correct either. $0.02 Tim _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
