MySQL 5.1 Released, Not Quite Up To Par 175
Mad Merlin writes "It's no secret that MySQL 5.1 has been a long time in the making, with the first beta release being in Nov 2005, but MySQL 5.1.30 has finally been released as GA. MySQL users can expect new features such as table/index partitioning, row based replication, a new plugin architecture, an event scheduler and a host of performance improvements from 5.1." Monty also had a blog post outlining some of the challenges faced in 5.1, including crashing bugs and a beta quality to most new features.
"Fair and balanced" summary?? (Score:3, Interesting)
Ryan Thiessen, a long-time 5.1 user, strongly rebuts Monty on his blog. [hideandsql.com]
well (Score:3, Interesting)
maybe they are just trying hard to be more like the commercial enterprise databases. my experience with oracle was that they have a lot more bugs than this - it's just you can't actually find out about them until you call support. Then you find out they have known about it for some time, they just don't publish it. They hide all this stuff instead and only let certain things out.
Re:"Fair and balanced" summary?? (Score:5, Interesting)
It sounds like MySQL could benefit from a more debian-like release criteria [debian.org].
Re:Wow (Score:5, Interesting)
I think his argument is more marketing/PR driven. His main point is valid, in that MySQL claims simplicity/lightness when they don't have the features, and claims maturity when they add them.
Re:news flash (Score:5, Interesting)
Oh, I agree, every product that's ever shipped has shipped with bugs.
But you gotta put this all in perspective, some glib talk about how everyone is equal in the eyes of bugs just doesn't apply here.
First off, the context. We're talking about a database, your warehouse for your most valuable asset. This is not a place where you want to encounter mistakes, and caution is the word. You might hear excuses for some, but those people are idiots. This is /inexcusable/.
If you read the article, the things he says basically boil down to "this product is as stable as a house of cards and if you use it, treat it with all the care and caution you'd give a newborn child." I'd love to pick an excerpt from the article and copy it here, but it's just TOO RICH. Every single thing this "Monty" says would make your average MySQL apologist cringe, and makes normal people and DBAs stomachs turn.
Honestly, I think I'm gunna be sick. I don't care if MySQL is a good product or a bad product as such, I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production." But having read this article and gotten a picture of what is, evidently, the thoughts of the minds supporting the creation and use of MySQL, it makes me ill. These people should just come out and say "there's no explanation we can give, this is crapware and we're really sorry if you got hosed by it. Don't use it at all if you aren't already." Instead this guy bends over backwards to explain how this broken database is actually quite useable, and ready for "general production" - how that's different from just "production" is clear: apparently "general production" refers to systems with zero value (less than my MythTV box, which will NOT be getting an update to this version).
PostgreSQL has the same issues (Score:5, Interesting)
It just has them on a different scale and there's a different release. If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since 2003 or before.
For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so.
The first time I used MySQL... (Score:5, Interesting)
I've used MySQL for years...
The same thing in MySQL would have taken me thirty seconds now, and no more than 15 minutes when I was starting out. With Postgres, it took me upwards of 20 minutes when it should have taken much less time.
That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.
I've used PostgreSQL for years, when I had to set up a MySQL database for some php app it took much more than 15 minutes to figure it out and get it running. The primary problem was MySQL's obtuse user management system.
With PostgreSQL I know that it's secure by default -- the default user has no password, so even if you enable password authentication it won't work (because it has no password!). You log in locally with trusted authentication, and issue the very logical CREATE USER. Edit the self-documented config file to allow remote hosts to access the database using your preferred authenticaion method, and you're done.
With MySQL, new users are automagically created by the GRANT command?! Huh? On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?
Oh, the default 'root' account has no password ...and allows access over the network. Wonderful. Okay, so to change that do I use root@% or root@computer? How do I know I changed the right one and there isn't still some root@something entry? SHOW TABLES is easy enough, how about SHOW USERS? Nope, that's not it.
Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user...'. The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.
To this day I'm not 100% sure if the MySQL install is secure. I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. There are some very strange queries in there - a lot of GROUP BY expressions that make no sense and aren't valid SQL. Some of it I'm not sure how it ever worked.
Re:Pet peeves (Score:2, Interesting)
-Does it silently accept CONSTRAINTS other than FOREIGN KEYs and then not use them? ...
Why is ignoring FOREIGN KEYs okay? A constraint is a constraint, IMO.
Last I checked FKs worked, if you're using InnoDB, and then only kinda (no deferred checking, which is the SQL standard default).
MySQL join performance deficiency, 3 orders of mag (Score:3, Interesting)