3 ms·

In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults cha

In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast? Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults? You don't like MySQL, I get it. Regardless of reasons, I don't think your view will change, so why enter every HN thread about MySQL just to repetitively bash MySQL? What's the purpose of this?

dijit 5y ago
The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why. The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that: a) it wasn’t built with that in mind and thus was experimental. b) was not enabled to ease adoption (this is kinda evil, in my personal opinion because it teaches bad habits) c) was considered a power-user feature, which is ridiculous. What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns, and people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”- which is absolutely not a good warning. If you listen to my rambling about the pain I’ve seen, and you still want to use it: at least it’s an informed decision. But pretending that all is well is not ideal, it doesn’t lead anyone to make better software or practices (MySQL) or better developers (because they don’t see footguns before they’ve sprung some self-inflicted wounds on themselves)
- evanelias 5y ago
  > The strict mode setting should have been the default since the beginning. I absolutely agree with that. But what's the point in talking about a terrible default that changed nearly 6 years ago, literally over and over again, year after year? > the only justification I can think of The real answer is almost certainly "backwards compatibility". Same reason many things in Windows are non-ideal, for example. Someone made a really bad technical decision early on, but fixing it overnight will break things for an utterly massive number of paying customers, so it can't be rectified without a slow transition plan. It happens. Yes, it absolutely should have been fixed on a faster schedule regardless, given its importance. But just because it wasn't, doesn't mean that the entirety of the piece of software is hopelessly flawed and everyone involved in its development is an utter cretin. Especially when a piece of software is multiple decades in age and has gone through multiple corporate acquisitions. > What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns What I've said? What footguns? I'm asking this honestly: what are you referring to? Let's recap this subthread: * @taywrobel said "it doesn't look like much new functionality has been introduced since 8.0.4" * I listed a number of new features introduced in 8.0 point releases, and explained that MySQL 8 is intentionally not doing SemVer * You said "that's pretty scary" without ever elaborating on which specific thing I said you find scary * I disagreed, given MySQL's stated written policy of not following SemVer * You mentioned something about defaults changing (??? this wasn't even a topic I mentioned by that point in the subthread) Now you're talking about footguns again, but the only one you're mentioning with any specificity was fixed many years ago. > people who have bought into the ecosystem like to exhalt that “you’re holding it wrong” Where has anyone said anything remotely like that in this subthread? Are you referring to my statement that the user should understand what's in an upgrade before upgrading? If so, I absolutely stand by that statement; it's utterly crazy to upgrade any database without even glancing at the release notes, let alone having a basic understanding of how the database vendor handles releases and versioning. This is operational basic practices 101, not about "holding it wrong". And for what it's worth, "people who have bought into the ecosystem" includes a massive chunk of the S&P500 using MySQL as a primary data store. If it's as deficient as you claim, why aren't all these companies going out of business?

dijit 5y ago

The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why. The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that: a) it wasn’t built with that in mind and thus was experimental. b) was not enabled to ease adoption (this is kinda evil, in my personal opinion because it teaches bad habits) c) was considered a power-user feature, which is ridiculous. What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns, and people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”- which is absolutely not a good warning. If you listen to my rambling about the pain I’ve seen, and you still want to use it: at least it’s an informed decision. But pretending that all is well is not ideal, it doesn’t lead anyone to make better software or practices (MySQL) or better developers (because they don’t see footguns before they’ve sprung some self-inflicted wounds on themselves)

evanelias 5y ago
> The strict mode setting should have been the default since the beginning. I absolutely agree with that. But what's the point in talking about a terrible default that changed nearly 6 years ago, literally over and over again, year after year? > the only justification I can think of The real answer is almost certainly "backwards compatibility". Same reason many things in Windows are non-ideal, for example. Someone made a really bad technical decision early on, but fixing it overnight will break things for an utterly massive number of paying customers, so it can't be rectified without a slow transition plan. It happens. Yes, it absolutely should have been fixed on a faster schedule regardless, given its importance. But just because it wasn't, doesn't mean that the entirety of the piece of software is hopelessly flawed and everyone involved in its development is an utter cretin. Especially when a piece of software is multiple decades in age and has gone through multiple corporate acquisitions. > What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns What I've said? What footguns? I'm asking this honestly: what are you referring to? Let's recap this subthread: * @taywrobel said "it doesn't look like much new functionality has been introduced since 8.0.4" * I listed a number of new features introduced in 8.0 point releases, and explained that MySQL 8 is intentionally not doing SemVer * You said "that's pretty scary" without ever elaborating on which specific thing I said you find scary * I disagreed, given MySQL's stated written policy of not following SemVer * You mentioned something about defaults changing (??? this wasn't even a topic I mentioned by that point in the subthread) Now you're talking about footguns again, but the only one you're mentioning with any specificity was fixed many years ago. > people who have bought into the ecosystem like to exhalt that “you’re holding it wrong” Where has anyone said anything remotely like that in this subthread? Are you referring to my statement that the user should understand what's in an upgrade before upgrading? If so, I absolutely stand by that statement; it's utterly crazy to upgrade any database without even glancing at the release notes, let alone having a basic understanding of how the database vendor handles releases and versioning. This is operational basic practices 101, not about "holding it wrong". And for what it's worth, "people who have bought into the ecosystem" includes a massive chunk of the S&P500 using MySQL as a primary data store. If it's as deficient as you claim, why aren't all these companies going out of business?