151–160 of 170 posts
Extremely important: If you use mysqldump, make sure it's also using utf8mb4 . There is a very high chance it defaults to utf8 and silently corrupts your data.
Thanks, that would be: mysqldump --default-character-set=utf8mb4 -u user database > dump.sql right?
Earlier quoted context omitted.
Imagine how many companies out there are relying on backups that are already corrupted... is your company one of them?
This is an important reason why testing your backups is a critical part of backing up.
With this I had used a backup and nobody even noticed the problem for three weeks, thankfully I had some more direct backups too...
> If you need a database, don’t use MySQL or MariaDB. Use PostgreSQL. This is stupid. There are pros and cons to every database. For example, MySQL allows you to set a trigger on an op, PostgreSQL requires you to write a function first.
> This is stupid. Talk about stupid, run this query on both Mysql and Postgres: select 0 = 'banana'; Make your own conclusion.
mysql> \W
Show warnings enabled.
mysql> select 0 = 'banana';
+--------------+
| 0 = 'banana' |
+--------------+
| 1 |
+--------------+
1 row in set, 1 warning (0.00 sec)
Warning (Code 1292): Truncated incorrect DOUBLE value: 'banana'This bit me hard many years ago in possibly the most frustrating bug I've encountered--frustrating because of the stupidity of MySQL's implementation. I had a utf8 MySQL database that was created back before utf8mb4 existed--this is, back in the days when emojis were just getting popular, but not quite popular enough to be on software keyboards; and when only a few people had smartphones and iPads, but not everyone.…
I think the lesson is "don't silently fail," and in that regard mysql has failed at learning that lesson over and over again to the point where the lesson is now, "don't use mysql" because what else can you do when dealing with such shitty software? This is far, far from the only stupid bug like this. Use mysql only if you don't care about preserving data. Period. There are many valid use cases that don't care about…
Yes, this really should have been the default from the start. It would have saved a lot of developers a lot of misery. But the past is the past. At least the default was finally fixed a few years back.
Many large companies using MySQL did proactively enable strict mode long before the default change, and they simply do not have any of these issues. That's a good thing considering the combined valuation of companies relying on MySQL is several trillion dollars. These companies do care about preserving data 100%, which is why strict sql_mode has existed as an option in MySQL for nearly 15 years now.
Earlier quoted context omitted.
I think the lesson is "don't silently fail," and in that regard mysql has failed at learning that lesson over and over again to the point where the lesson is now, "don't use mysql" because what else can you do when dealing with such shitty software? This is far, far from the only stupid bug like this. Use mysql only if you don't care about preserving data. Period. There are many valid use cases that don't care about…
does that affect MariaDB as well? That would only leave people to PostgreSQL or NoSQL Databases like MongoDB AFAIK. I've never been a fan of MySQL, but MariaDB always seemed to me like the spark of hope that was left in there.
That's only true if you ignore the non-free options, which is what, I would argue, Postgres and Mysql were originally competing against in the first place.
> MariaDB always seemed to me like the spark of hope
Still, I'm not entirely sure what point you're trying to make. That is, what are you hoping for?
Earlier quoted context omitted.
Imagine how many companies out there are relying on backups that are already corrupted... is your company one of them?
This is an important reason why testing your backups is a critical part of backing up.
Since the complaint here is of corruption that is silent, the level of testing required to catch it would be extraordinary.
Earlier quoted context omitted.
> One factor is that back in the early 90s China was still an economically backward, closed Communist enclave barely more integrated into the global economy I'd disagree, China was well on the way to becoming an economic power house in the early 90's: https://en.wikipedia.org/wiki/Five-year_plans_of_China#Eight...
But it wasn't yet. Decades later, the infrastructure stabilized (although in 2010 consumer network products were still incredibly chaotic).
Earlier quoted context omitted.
This is an important reason why testing your backups is a critical part of backing up.
This is oft-repeated advice, but, in this context, it ends up being little more than a platitude. Since the complaint here is of corruption that is silent , the level of testing required to catch it would be extraordinary.
Earlier quoted context omitted.
Oh. In that case, you do mean ASCII, methinks (which also works), with Latin-1 you're shooting yourself in both feet. (Looks for link to "falsehoods programmers believe about encodings")
To my understanding, ASCII basically only covers English and Italian well, whereas Latin-1 covers most Western European languages — which includes the main languages of the Americas (Spanish, English, French, Portuguese).
Accented letters just don't appear that much prominently as in French or Spanish, and distinctions of acute and grave accents are often nowadays lost even on native writers if it wasn't for spellcheckers.
Earlier quoted context omitted.
> Possibly my favourite thing about the rise of emoji is that they’re not Basic Multilingual Plane When can we have user-defined glyphs/emoji, where SVG is embedded in the unicode string?
You’d just define two code points that switches into and out of SVG mode. (The second is only necessary for performance, so you can scan quickly without needing any sort of XML parser!)