A Tale of Two MySQL Bugs 191
New submitter Archie Cobbs writes "Last May I encountered a relatively obscure performance bug present in both MySQL 5.5.x and MariaDB 5.5.x (not surprising since they share the same codebase). This turned out to be a great opportunity to see whether Oracle or the MariaDB project is more responsive to bug reports. On May 31 Oracle got their bug report; within 24 hours they had confirmed the bug — pretty impressive. But since then, it's been radio silence for 3 months and counting. On July 25, MariaDB got their own copy. Within a week, a MariaDB developer had analyzed the bug and committed a patch. The resulting fix will be included in the next release, MariaDB 5.5.33."
Re:A Post with an Agenda (Score:2, Informative)
Re:who cares? (Score:4, Informative)
[Citation Needed]. Among industry watchers the two most popular RDBMS systems are considered to be Oracle and Microsoft's SQL Server. MySQL is in the same ballpark, but it certainly doesn't have a large lead. Here's one survey [db-engines.com] showing that via a few metrics they combine. You'll get the same sort of ranking if you dig into most market surveys.
Re:who cares? (Score:4, Informative)
Re:What about 10 year old mysql bugs? (Score:5, Informative)
I don't think it's possible for MySQL to get the "C" part in ACID right without a total rewrite, which seems unlikely under Oracle's watch. There used to be all sorts of trivial ways you could insert garbage data into MySQL, things like February 31 being a valid date or numbers going into boolean fields. They added this strict mode [mysql.com] as a way to add validation for most of that. But strict is a client setting. All it takes is one client that ignores this, and the engine will still let you put garbage into there--values that are not going to be valid if you later work on them using a strict setting client. If you can put data in one end of that's not correct when read by another client, that's the exact opposite of a "consistent" database. It boggles my mind that anyone finds this acceptable. I guess people who do all their validation on the client are fine with it maybe? I can't explain how people who don't understand databases at all make their decisions.
I don't follow MySQL closely enough to know if they're still silently truncating data sometimes too, but that's been a nagging problem over the years too. Strong validation of data is like security: you don't just bolt it on later. It's something that needs to be enforced in as many places as possible in the code, if you want any hope of getting it right and bug free. If you actually want data to be validated in all situations, you need to use something like PostgreSQL instead. There even new types you add to the database can execute any check constraint function you want before that data is allowed in, period. That overhead contributes to why MySQL is faster on trivial things, but sometimes you get what you pay for.
Re:who cares? (Score:4, Informative)
What specifically makes SQLlite not a "standalone" database?
The 'server' is embedded in the application, which means one instance per app instance. A true standalone RDBMS runs (a minimum of) one instance that multiple (instances of) apps query.