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.
Re:news flash (Score:1, Informative)
I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy - what software engineers refer to as the waterfall model. In such a scenario, bugs will appear in earlier releases and decline in number sharply over time. Closed source projects tend to operate on the more classical release schedule, which tends to be a lot slower with a lot more expansive software lifecycle, but SHOULD produce far far fewer bugs in each release.
MySQL, with the current Oracle owners, seems to have moved to more of the classical mindset. That's fine and I personally don't think there's anything wrong with it if it's done right. But to be done right, you need fewer bugs in a release than the rapid-cycling of the RERO approach, and should aim for code of a quality comparable to RERO over the same timeframe.
It is clear in this case that MySQL has failed the test. It is a good product, but the new methodology is fixing less than the old methodology. That needs to be when the developers stop and think about whether they want to try switching to something else or go back to what had worked well in the past.
Just two things.
1) The waterfall model is the old slow model for software development.
2) Sun MicroSystems owns MySQL, not Oracle.
I think your post is now totally invalid...
5.0? that so? (Score:3, Informative)
I've been using 5.0 in production for well over a year and found no 'critical' bugs. (For most of that time I had access to MySQL's paid support.)
As Ryan said there is no such thing as bug free software but there is such a thing as production-ready software. MYSQL 5.0 HAZ IT.
Re:Wow (Score:5, Informative)
MySQL is very easy to use and configure the first time. Postgres isn't nearly as simple
I've heard this a few times. I've installed PostgreSQL on Windows, Linux, FreeBSD and OpenBSD. Every time, the process has been:
How does MySQL simplify this?
Re:Not a question forum (Score:3, Informative)
If it returns 1, the column has data. If it returns 0, it's null.
Re:Wow (Score:3, Informative)
One thing I like about postgresql vs MS Sql is the triggers. MS SQL triggers are after-insert, per statement only, IIRC. Pg triggers are per statement or per row, before or after. There's also a rule system and the ability to rewrite the query, for updateable views or other tricks. The lacking features are clustered indexes, replication, and partitioning. I'll also mention hash indexes -- it has them, but they're not journaled, and they're not generally recommended. I'm not going to comment on MySQL since I haven't used it since 4.x and it sort of has triggers now.
Oh, also, the pgpsql stored procedure language is similar to oracle's psql and fairly fun to program in.
Re:MySQL x.1 releases gives me the creeps (Score:2, Informative)
So, you're waiting for MySQL 5.11 for Workgroups?
Re:Wow (Score:4, Informative)
.... Things like "SHOW TABLES" are either considerably more difficult in Postgres or harder to find out. ....
More difficult? Harder to find out? Consult help by typing \? and you will see this:
[snip]
Informational
\d [NAME] describe table, index, sequence, or view
\d{t|i|s|v|S} [PATTERN] (add "+" for more detail)
list tables/indexes/sequences/views/system tables
[snip]
Then type \dt to show the tables. To me that does not present it seld as more difficult or hard to find out.
Re:news flash (Score:3, Informative)
Re:Wow (Score:3, Informative)
Re:well (Score:5, Informative)
To step away from the metaphor for a second - I have had severity 1 service tickets open with Oracle support for over a day that ended up being unpublished bugs that were fixed with a patch that was not available until you knew you had run into the bug. Sev 1 to be clear is production systems down.
I'll second this. We just ran into such a bug when trying to restore a database.
The application connecting to the database was upgraded, and something went wrong when it tried to modify the schema, so we rolled back to the backup taken immediately before the start of this. Normally, this would have been simple, but apparently there's a bug with our version of Oracle that caused the restore to fail. Luckily, it only took an extra couple of hours to work around and we were still in our planned outage window, but it still sucked that it was a bug known to Oracle.
Of course, we didn't hit the Oracle bug in our development and test systems, because the application didn't fail in the schema update on those, thank's to Mr. Murphy.
Re:The first time I used MySQL... (Score:3, Informative)
The manual seems to describe this in the connection access [mysql.com] and request access [mysql.com] sections. It answers your question on precedence (most specific to least specific, first match wins), but not the others. You would assume that localhost or 127.0.0.1 would work for connections initiated over the loopback interface (i.e. where the client application connects to localhost or 127.0.0.1), but that you would need to use the real public host name if the application is connecting via that. That's how networking works. Interesting point about reverse name lookups not working. Hopefully it's getting the name from there, and not just using whatever hostname the client asserts when it connects. You'd want to use IP addresses rather than host names to be safer. They mention that wildcard and host/subnet notation is supported.
Well, you now know the precedence. The pages I linked to before also tell you that MySQL determines these based on the values in the user table (i.e. mysql.user), so you could just do a SELECT * FROM user WHERE User = 'root' to see what entries exist. From there, you would either have noticed that the passwords were hashed, and so found the password hashing [mysql.com] section and executed an UPDATE user SET PASSWORD = PASSWORD(password) WHERE..., or you would have found the SET PASSWORD [mysql.com] documentation, or a quick Google search would likely have yielded the more common advice [cyberciti.biz] to just do mysqladmin -u root password NEWPASSWORD.
Re:Wow (Score:1, Informative)
MySQL has been able to do master/master replication for at least 3 years now.
I know this painfully since that was when I lost the database argument at my current employer (I was advocating PostgreSQL with others arguing for MySQL.) It was the one feature that others with more authority said was absolutely necessary, so we went the MySQL direction. And it's caused no end of grief. To start with, the master/master replication is buggy and will frequently just stop replicating in one direction or the other. It's easy enough to fix (once you've learned how...the documentation could be a lot more thorough), but it's annoying that we have to do it so frequently.
But more annoying than that is that MySQL expects/requires you to write some pretty crazy SQL to get around its inadequacies. Things like having to add an ORDER BY to your update statements since MySQL is incapable of deferring unique constraints until after the entire query has been processed.
And my personal favorite is when you're selecting data from one or more tables with a large number of columns and you apply a sort. It turns out if you select the fields you want to get back in the initial query, result set size will convince MySQL that it needs to do a file sort since it can't fit everything in memory. But if you select just the primary keys from the tables from which you want to retrieve data, ordering them with the exact same ORDER BY, LIMIT and/or GROUP, MySQL will happily perform that sorting in memory in the vast majority of the cases we've run into. So we end up having a ton of queries in our application that sort a result set of primary keys with the result then joined back against the very same tables to populate desired data fields.
Re:Wow (Score:3, Informative)
... master/master replication is buggy and will frequently just stop replicating in one direction or the other. It's easy enough to fix (once you've learned how...the documentation could be a lot more thorough), but it's annoying that we have to do it so frequently.
You can also file bugs against the docs (Category is "MySQL Server:Documentation"). Please do so.
It would help resolve the issue more quickly if you could supply at least some of the information that you think is missing.
Thanks for helping other MySQL users!