Edit. 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.
Edit. Fuck HN.
Time for a WTF MySQL Moment
11–20 of 121 posts
Re: Time for a WTF MySQL Moment
#12Edit. Fuck HN.
A vast majority of developer issues can be boiled down to RTFM, as usual.
Re: Time for a WTF MySQL Moment
#13Edit. Fuck HN.
The issue is that the authors expectations didn't match with reality, because he hadn't yet read the docs.
The moment the author wrote "I normally use PostgreSQL" I knew that this would devolve into a "MySQL Bad" even if it's well defined and documented behavior.
Re: Time for a WTF MySQL Moment
#14Earlier quoted context omitted.
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.
Edit. Fuck HN.
MySQL not having a proper type to express time spans seems like a fault to me, and "poor design". Of course you can just use an integer for it, but that is a slippery slope, in the end you'll find that you can use strings or byte arrays for everything and you end up with no type system at all.
The surprise here is not that the type has limits but that they are so awkward and that there is no better strongly-typed alternative.
Re: Time for a WTF MySQL Moment
#15I 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.
How does a corrupted index and a TIME type come into play with each other?
Re: Time for a WTF MySQL Moment
#16> 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.
Sorts better that way.
Re: Time for a WTF MySQL Moment
#17> 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
#18Earlier quoted context omitted.
> "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 lim…
I agree it's not a necessary change. But, on the other hand, how much compatibility would it really break? I cannot imagine much applications are dependent on MySQL throwing an error at 800-odd hours (and it would arguably be a very strange design decision).
Re: Time for a WTF MySQL Moment
#19I'm a big fan of Postgres too for a number of reasons, but this issue is pretty clearly documented so I'd like to counter with an issue I hit in Postgres recently that is terribly documented. UNNEST works a bit funky, and in particular it works super funky if you have multiple calls in the same select statement (or any set expanded function calls it turns out). There's a bit of a dive into here[1] (though that is out of date - PG10 no longer follows the different array sized result, it uses null filling) which I managed to find after struggling with an issue where an experimental query was resulting in nulls in the output while unnesting arrays without nulls.
All DBs have their warts and while MySQL has an over abundance of warts they tend to be quite well documented. The warts that postgres has tend to be quite buried and their documentation is very good for syntax comprehension but rather light when it comes to deeper learning.
1. https://stackoverflow.com/questions/50364475/how-to-force-po...
Re: Time for a WTF MySQL Moment
#20Earlier quoted context omitted.
> "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 lim…
The unforgivable thing here isn't the anachronism -- it's the lack of a suitable replacement. If you want a full i64 worth of duration at a reasonable resolution, you're on your own.