Slashdot Mirror


MySQL 5.1 Released, Not Quite Up To Par

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.

5 of 175 comments (clear)

  1. Wow by Whitemice · · Score: 5, Insightful

    Impressive, now MySQL can have features other databases (PostgreSQL among others) have had for *years*. I've never understood; people like MySQL because it is "light", "simple", "easy", blah, blah.... and yet they add all these enterprise features that then everyone will laud about how MySQL is "growing up" or some such. MySQL is one of the best examples of self redefined success I think I've ever seen.

    If you want these features why not use a database that has had them for a long time, where they are better tested, and possibly get better performance under concurrent load as a side benefit.

    --
    Using "Common Sense" is being either to arrogant or to ignorant to ask people who know more about something than you.
  2. Re:well by stoolpigeon · · Score: 5, Insightful

    I'm not sure what you are trying to say. If we have to play car analogy - lets say both cars engines will fail if you go over 80 kmh on a sunday while wearing blue. One vendor will tell you before you buy the car - the other waits until you've been on the phone with roadside assistance for a couple days. The severity of the issue is the same - it's just how the manufacturer handles it that is different.
     
    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 worked on a project with an Oracle consultant who had been on his own before he joined Oracle. I asked why he made the switch and he told me it was for one main reason - so that he would get full access to all the documentation, including all the bugs and open issues.

    --
    It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
  3. Re:"Fair and balanced" summary?? by dfdashh · · Score: 5, Interesting

    With all due respect to Ryan, I agree with Monty here. Not just 5.1, but the whole MySQL 5.x tree has been shipping with release critical bugs. What's more, some of those bugs (like the one that has been open since 2003) have lowered priority now because "people know about them."

    It sounds like MySQL could benefit from a more debian-like release criteria.

    --
    df -h /my/head
  4. Re:news flash by kwerle · · Score: 5, Funny

    Cognitive dissonance is a wonderful thing.

    No, it's a terrible thing.

    But I want it. Badly.

  5. The first time I used MySQL... by quantum+bit · · 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.