Time for a WTF MySQL Moment
gbl08ma.com
Time for a WTF MySQL Moment
1–10 of 121 posts
Re: Time for a WTF MySQL Moment
#2MySQL has come a long long way indeed but not enough to make me turn away from Postgres.
Re: Time for a WTF MySQL Moment
#3So, mysql is preserving backwards compatibility? Good. A flag to break this backwards compatibility and offer a larger range is probably warranted, but until that's implemented this behavior is fine.
"I think this is stupid" is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning.
But of course, MySQL bad, PostgreSQL good.
Re: Time for a WTF MySQL Moment
#4I learned the semi hard way on PoC system where the Mysql index corrupted.
I was lucky and could simply redeploy my application, but I have never used Mysql since.
Re: Time for a WTF MySQL Moment
#5So, mysql is preserving backwards compatibility? Good. A flag to break this backwards compatibility and offer a larger range is probably warranted, but until that's implemented this behavior is fine. "I think this is stupid" is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning. But of course, MySQL bad, PostgreSQL good.
> "I think this is stupid" is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning.
True. But his argument seems to be in the direction of "this is highly unexpected behaviour" and I tend to agree. The number of applications broken by extending the date range probably dwarves to the number of bugs avoided by not having the time span break at such a strange length.
Re: Time for a WTF MySQL Moment
#6Edit. Fuck HN.
Re: Time for a WTF MySQL Moment
#7> 1 bit sign (1= non-negative, 0= negative)
First time I ever saw a number where the leading sign bit has to be set to 1 to indicate non-negative.
Re: Time for a WTF MySQL Moment
#8So, mysql is preserving backwards compatibility? Good. A flag to break this backwards compatibility and offer a larger range is probably warranted, but until that's implemented this behavior is fine. "I think this is stupid" is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning. But of course, MySQL bad, PostgreSQL good.
> "I think this is stupid" is a really poor reason to break backwards compatibility, despite how many other software projects use this reasoning. True. But his argument seems to be in the direction of "this is highly unexpected behaviour" and I tend to agree. The number of applications broken by extending the date range probably dwarves to the number of bugs avoided by not having the time span break at such a strange…
> "this is highly unexpected behaviour"
The behavior in question is having an upper and lower bound on a time interval. This strikes me as highly expected behavior.
The maximum on the interval is lower than the author expected; and reading the docs quickly cleared up what the interval maximum is.
The entire rant boils down to "MySQL's choice to keep backwards compatibility is stupid, because I think this interval limit should be larger."
Re: Time for a WTF MySQL Moment
#9Edit. Fuck HN.
The issue seems to be that the .NET core provider for MySQL that OP uses maps the .NET Timespan type to this MySQL TIME datatype. They probably didn't think this through.
Re: Time for a WTF MySQL Moment
#10This gives me flashbacks to the DOS filesystem timestamps. It's exactly the same mistake. By splitting the date into multiple fields, bits are wasted. If they hadn't tried to be smart and just made it one number, it would've been more precise with a wider range.