Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Databases Programming Software IT

MySQL 5.0 Candidate Released 339

Brian "Krow" Aker (Former Slashdot Coder now MySQL Employee) writes "I am pleased to announce the release candidate for MySQL 5.0. This version has been in development now for three years. We have worked to add update-able views, ansi stored procedures, and triggers. In addition we have added a number of fun features that we are experimenting with and resolved issues with bad data inserts (which personally annoyed the hell out of me when we rewrote Slashdot a couple of years back so I am happy to see this issue go away). We look forward to feedback on the candidate and will show some love for bug reports."
This discussion has been archived. No new comments can be posted.

MySQL 5.0 Candidate Released

Comments Filter:
  • by CyricZ ( 887944 ) on Tuesday September 27, 2005 @09:03AM (#13657557)
    It's time for somebody to do a new, impartial study regarding the performance and feature benefits of this new release of MySQL, PostgreSQL, Firebird, SQLite, and perhaps other open-sourced relational databases.

    • And of course you can't include Oracle in any impartial study.
      Hmm... do I smell... fear?
      • Correct []. If you're measuring performance, then you *can't* include Oracle.
      • by tdemark ( 512406 ) on Tuesday September 27, 2005 @09:18AM (#13657639) Homepage
        And of course you can't include Oracle in any impartial study.

        You could, except for the fact that the license you just paid thousands per CPU for doesn't allow you to publish [] the results.
      • Had you read my post, you would have seen that I limited it to open source relational databases. Oracle is not, as of now, an open source piece of software. And I believe their licensing agreement prohibits the disclosure of benchmarking data.

      • Easy just report;
                Performance Prettiness Completeness
        1. MySQL Firebird Postgress
        2. Postgress MySQL
        3. Postgress Firebird
        4. Firebird MySQL
        5. ... ... ...

        Then oracle has no problems with the report since you are _not_ reporting anything about them.
    • Call up Microsoft, I'm sure they'd love to sponsor the study.
    • by ceeam ( 39911 ) on Tuesday September 27, 2005 @09:43AM (#13657781)
      But puhhhlease, don't put MySQL performance based on MyISAM and feature set based on InnoDB! Stick to either one. BTW - last I checked for myself, Firebird was beating _even_ MyISAM for raw speed on simple queries for local engine. Something I did not expect. Oh, yeah! When comparing performance please include results for local engine AND over-the-LAN performance. Different beasts have different protocol issues that show up when using "real" LAN and may be masked when using "local" engine mode. For example, MySQL has very simple and LAN-friendly protocol. Unlike Firebird, but it's still ok. And MSSQL, EG, has very, very serious issues when used for lots of "simple" queries.
  • by digidave ( 259925 ) on Tuesday September 27, 2005 @09:05AM (#13657569)
    Every time any database is mentioned on Slashdot we get a load of comments about how MySQL is not a "real" database because it doesn't support {insert random feature here}.

    Is it a real database yet?
    • by mmkkbb ( 816035 ) on Tuesday September 27, 2005 @09:07AM (#13657586) Homepage Journal
      Actually, most of those features are in MySQL 4. The two big problems are: Lots of people still run MySQL 3.x, and these features only work for certain table types.

    • Of course it's a real database. People have been successfully using it for years. Maybe at one point it didn't comply with the formal definition of a "relational database" due to missing features, but nevertheless was still a suitable product for many. And that alone is enough for it to be considered a "real" database.

    • by codesurfer ( 786910 ) on Tuesday September 27, 2005 @09:15AM (#13657622)
      I'd say so...despite the detractors, I've been able to use MySQL for many highly trafficed sites, and heavily used applications. Does it have the full robustness of Oracle? Of course not, but it also does not come with the accompanying price tag. Choice of db software is just that...a choice. I can envisage situations in which I may prefer having Oracle, but to be honest, MySQL addresses most day to day situations more than adequately. It's a real db, IMO.
      • Agreed - it is a real database, that can do real work and provide real value.

        However, it has a history of inexcusible quality problems with silent errors, silent data truncations, etc, etc. The leadership of mysql also has famously stated that almost nobody really needs transactions. So, there's quite a lot of skepticism about the company and the product.

        MySQL might turn that around. Hopefully they will.

        Back to price - the difference isn't always so huge: I know that db2 is around $700 for a license lim
        • People have mentioned in a few other posts that DB2 is "only" $700. People then mention that MySQL is $500. I would argue that this isn't the case. I would say that MySQL and PostgreSQL are free and DB2 starts at $700, but that cost is just the beginning. What happens if you run a processor with multiple cores? How much does it cost if you migrate off of X86 to Sparc? How much if you want to run it on one of their mainframes? It is my experience that Oracle and IBM tend to "give" away some of their p
          • This isn't the case with PostgreSQL or MySQL. You never get that "drug pusher" type of attitude.

            Are you kidding? MySQL is TOTALLY a "get our hooks in drug pusher" kind of company. They're the "Project Mayo" of the DB world. Their development/business model revolves around getting everyone onboard with the open source version and then exploiting the open source development community with their policy that copyright to patches and improvements must be transfered to MySQL so they can then be sold closed-
    • We have worked to add update-able views, ansi stored procedures, and triggers.

      It's much closer. As to whether it has ALL of the features yet, I personally don't know because I don't use it. Updateable Views, Stored Procedures and Triggers are all a big step in the right direction. Now, for anybody who's serious about their data (like I am), there will be a waiting period of a few years while the kinks are worked out, before it's really ready to be compared to other, more mature databases that have had
    • by Fished ( 574624 ) <> on Tuesday September 27, 2005 @09:23AM (#13657668)
      The point is not whether MySQL is a "real" database. Clearly, it is a real database that is capable of doing real work.

      The point is that, even in recent versions, MySQL has some serious limitations that other OSS databases (e.g. PostgreSQL) do not suffer from, and no really significant corresponding advantages. MySQL was not designed from the ground up to be many things it is now trying to be--it was not designed to support transactions, it was not designed to support foreign keys, it was not designed to support stored procedures. It was initially conceived as a small, fast database for managing very large datasets in a warehousing sort of role. PostgreSQL, on the other hand, was always conceived of as being a heavier-duty database, and this shows in terms of feature completeness and SQL standard compliance.

      Given that the performance differential (which was always overstated) has been overcome, why would you want to go with MySQL only to discover what the latest feature to be missed was? What's the advantage to MySQL?

      • it was not designed to support transactions, it was not designed to support foreign keys

        Forgive my ignorance, but if a plug-in design allows for table handlers to be added that support missing feature(s), what is inferior/wrong with that? It would seem MySQL was designed with modularity in mind. InnoDB supports the features you mentioned, and that I quoted, so why is that less desireable than having the table handler builtin?

        What's the advantage to MySQL?

        For me, the massive community is a big plus. A r

        • by kpharmer ( 452893 ) on Tuesday September 27, 2005 @10:06AM (#13657963)
          > InnoDB supports the features you mentioned, and that I quoted, so why is that less desireable than having the table handler builtin?

          Because it is core functionality.

          Having a separate product responsible for managing io may be one of the reasons that mysql's optimizer is so primitive - and may be a reason why they will struggle to improve it. Note: the optimizer is the component responsible for determination of how your joins will be performed under the covers - mysql is notorious for failing to use indexes it should, using indexes when it shouldn't, never using star-joins, five-way joins that day 10x as long as they would in any other database, etc.

          Perhaps it's also why views took forever to implement, and materialized views might take another forever.

          It's also perhaps the reason for all the inconsistencies in table creation.

          There are also benefits to using innodb - it has undoubtably speed up mysql's development by several years. Still, now it's a boat anchor that should be abandoned.

          > For me, the massive community is a big plus. A rich set of tools is another advantage.

          yep, although it may be the only advantage that mysql has, it's a huge one.
      • I can tell you what MySQL advantege over PostgreSQL and Firebird was *for me*:
        1) Easy to install in Windows. PostgreSQL is (AFAIK) goof _now_ but was not then. Firebird was/is OK in this area.
        2) "Spatial" type/index, Fulltext index. Postgis is available for PostgreSQL but as plugin, not out-of-the-box, fulltext is (AFAIK) beta and not very unicode-reliable. I prefer both things to be integrated as I distribute DB engine with my SW. Firebird miss spatial type (just as MS SQL, for example (!)) so it is us
        • TSearch2 is a full text search module for PostgreSQL that has been available for a long time. It's stable and not in beta.

          What's wrong with modules? They're great. It means that you can upgrade TSearch2 or some other module without waiting for the next release of PostgreSQL. It's not difficult at all to install the modules, just copy some files and run a SQL file.

          I think that PostgreSQL making use of it's extensibility by forcing some functionality out into modules was very successful from a technological s
      • User community, user community, user community.

        MySQL is a great example of how the GPL can motivate the use of a product. Because MySQL was one of the earliest DBMS to go GPL, it got embedded into a huge number of GPL applications, and developed the wide range of users that has made getting answers, documentation, tutorials, discussion, etc much easier than its BSD-licensed counterpart. Same phenomenon as Linux and *BSD. Is Linux "better" than *BSD? Who knows, but it's so much more widely used that it's
        • Your argument has a weak point - there's no reason why you couldn't instead embed a BSD licensed DBMS in a GPL application. It wasn't going GPL that 'empowered' these developers. BSD licensing has no restrictions other than a credit line.

          I'm not saying the rest of your points aren't valid - but saying that MySQL is where it is today because it was GPL just doesn't fit. I think it's where it is today because it started out dead simple, and people latched onto that - just like PHP.
          • Of course you can embed a BSD-licensed DB into a GPL project - the BSD license permits that, along with everything else.

            The point is this: Postgres has existed much longer than MySQL. Yet as the OSS, and particularly GPL, movement caught on, and a large number of OSS apps were produced, MySQL managed to be included in many of them, and Postgres and Firebird did not. I don't really think all that many people sat down and evaluated Postgres vs. MySQL - they just learned about MySQL, heard that it was GPL (a
      • Given that the performance differential (which was always overstated) has been overcome

        Do a side-by-side comparison on your own data. For me, the performance differential has not been overcome. In MySQL, my reports take about 10 minutes to run. In Postgres, they take 3-4 days. When I mentioned this to our local Pg-fanboys, they came in, gave Postgres its own dual-processor server, extra ram, changed my column datatypes, made a slew of indexes, and reduced the report time from 3-4 days to 3-4 hours. I a
        • I don't want to start a holy war here, but what is the deal with Postgres performance? I've been sitting here at my freelance gig in front of a 4 way Xeon box running Postgres for about 20 minutes now while it attempts to do a simple select from a single indexed table with only 300 rows. 20 minutes. At home, with MySQL on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this rig, the same operation would take about 2 seconds. If that.

          In addition, during this select, no oth
          • VACUUM (Score:3, Interesting)

            I had a similar problem only this morning. I deleted all the rows from a table (by using DELETE FROM) and SELECT COUNT(*) went from sub-second to two minutes.

            That's after going from 400,000 rows to zero.

            VACUUM ANALYZE made no difference; however VACUUM FULL sorted it out. You should really have auto vacuum running, but for the dev I am doing I prefer to do it by hand.

            From what you're saying, this could be the reason why it takes so long.

            For what its worth, I've moved to Postgres because it's just so more
    • by Anonymous Coward

      I cannot trust MySQL to store data reliably until the MySQL give a clear explanation as to why they made decisions that no competent database developer would ever make.

      For example, you have a constraint limiting a column to a maximum of 99. You attempt to enter 999 as a value, and it got silently altered to 99. Not only is it against SQL standards, it's also completely and utterly the opposite of common sense.

      Just once, I'd like to hear a MySQL developer say "yeah, I don't know what we were thinkin

      • Ok, here goes... (Score:4, Informative)

        by krow ( 129804 ) * <[gro.tnegnat] [ta] [nairb]> on Tuesday September 27, 2005 @05:13PM (#13661849) Homepage Journal
        a MySQL developer say "yeah, I don't know what we were thinking, that's a really fucked up thing to do" Yep, its a fucked up thing. This is why we implemented strict mode for 5.0. In 4.1 you get warnings, in 5.0 if you are using a transaction table it tosses an error. If this is an issue, upgrade to 5.0. Personally for me it is.
    • It is absolutley a real database now.

      IMHO, what prevented MySQL from being a 'real' db wasn't missing transaction feature X, but data truncation. For anyone who hasn't run into this MySQL has a really nasty habit of truncating data if it won't fit into a field. Occasionaly this is desired for logging and non-critical information, but it can cause major problems that are incredibly difficult to track down. The solution up until now was to over-estimate column size and hope for the best (I'm aware that
  • Add bloat, stay fast (Score:3, Interesting)

    by jurt1235 ( 834677 ) on Tuesday September 27, 2005 @09:05AM (#13657574) Homepage
    I welcome stored procedures triggers very much, as long as they are fast enough to compete with the current "just program it yourself in you chosen language" style. Anyway: Another stored procedure language to learn.
    • In PostgreSQL, you can write your stored procedures in
      Python, Perl, and a couple of other languages. It probably
      won't be too long before MySQL allows the same thing. With
      any luck, you won't need to learn a new language at all.
    • by DrXym ( 126579 )
      Unless every single app you connect to the DB contains trigger-like code and you don't expect your users to abuse or circumvent the trigger-like code, I fail to see why you would not want them.

      As for stored procedures, I thought the whole point of them is that they are precompiled and live on the server side. Not only does this make them faster but you can change or modify the stored procedure without having to change the client code. Again, what's the point of not wanting them?

      Is there any evidence to

  • by CyricZ ( 887944 ) on Tuesday September 27, 2005 @09:06AM (#13657576)
    How does the source code quality of this new release of MySQL compare to that of projects like PostgreSQL or Firebird, which have a far longer history and/or were formerly commercial developments?

  • Something that is comparable and as easy to use as SQL Servers Enterprise Manager. The tools available on MySQL's site aren't very good. My main concern is easy importing and exporting to and from Microsoft Access. For example I can just copy records from access and easily paste them into SQL Server. Thanks for the help.
  • by scorp1us ( 235526 ) on Tuesday September 27, 2005 @09:19AM (#13657646) Journal
    After the 3.x series, the license changed drastically. Of course you won't find this discussed much. The permitted uses of MySQL as GPL are significantly reduced. You can only use MySQL in conjuction with OSS. Previously, you could use MySQL in a non-GPL environment under several permissive conditions. The new license is so restrictive now that a special exception is made for PHP

    Specifically: []

            * MySQL is free use for those who are 100% GPL. If your application is licensed under GPL or compatible OSI license approved by MySQL AB, you are free to ship any GPL software of MySQL AB with your application ('application' means any type of software application, system, tool or utility). You do not need a separate signed agreement with MySQL AB, because the GPL license is sufficient. We do, however, recommend you contact us as there usually are good opportunities for partnership and co-marketing.

            * Under the Open Source License, you must release the complete source code for the application that is built on MySQL. You do not need to release the source code for components that are generally installed on the operating system on which your application runs, such as system header files or libraries.

            * Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.

            * You are allowed to modify MySQL Software source code any way you like as long as the distributed derivative work is licensed under the GPL as well.

            * You are allowed to copy MySQL binaries and source code, but when you do so, the copies will fall under the GPL license.

            * Optional GPL License Exception for PHP. As a special exception, MySQL AB gives permission to distribute derivative works that are formed with GPL-licensed MySQL software and with software licensed under version 3.0 of the PHP license. You must obey the GNU General Public License in all respects for all of the code used other than code licensed under version 3.0 of the PHP license.

            * FLOSS License Exception. We have created a license exception which enables Free/Libre and Open Source software ("FLOSS") to be able to include the GPL-licensed MySQL client libraries despite the fact that not all open source licenses are compatible with the GPL (this includes the PHP license version 3.0). Read more about the FLOSS License Exception.

    Considering the new license and still lacking features, there is little reason to use MySQL. Postgres has "all that anda bag of potato chips."

    • * You are allowed to copy MySQL binaries and source code, but when you do so, the copies will fall under the GPL license.

      Loophole. So take their code, release it under GPL. Boom instant open source project.

      • No, their license is giving you more than the GPL. One of the GPL's biggest problems is it doesn't play friendly with many other OSS licences, so they are putting in a special exception to allow you to link to more things (such as things under the PHP licence). Of course, as you say, you can always have the GPL if you don't like their licence.
      • "So take their code, release it under GPL"

        They already do this. That's the problem with this whole license foolishness is that everyone has somehow gotten the impression that MySQL isn't distributing GPLed code. What they are doing is pointing out the restrictions that the GPL places on users of library code (which the authors of the GPL were so strongly aware of that they created the "Library General Public License" with more permissive terms, but later decided that they didn't like that and re-named it th
    • by Anonymous Coward
      The license you describe doesn't say anything about server usage.
      Clearly, the main-use for MySQL lies in server-client architecture. As long as you do not ship your self-created web-application, I see no reason you should be suspicious about MySQL.
    • The license exception is meaningless.

      Mysql is GPL.. you link it with an LGPL library & distrubute.. OK the license exception appears to allow that.

      Now someone links the LGPL library with a closed source application. The LGPL allows that. However the GPL in MySql does not.

      Only two interpretations are then possible:

      1. The whole package must be GPL - the license exception is meaningless.
      2. The license exception holds.. the GPL in Mysql is meaningless.

    • by Scarblac ( 122480 ) <> on Tuesday September 27, 2005 @09:42AM (#13657776) Homepage

      In short:

      • If you don't distribute MySQL, you're under no restriction whatsoever
      • If you do want to distribute, MySQL is GPL
      • Besides, MySQL goes out of their way to give you even more freedom to distribute it if you want to bundle it with stuff that has one of several incompatible licenses

      Sounds good to me!

      • by jadavis ( 473492 ) on Tuesday September 27, 2005 @11:17AM (#13658482)
        If you do want to distribute, MySQL is GPL

        The problem is that the client library is GPL, not LGPL as one might expect.

        That means that any application that you distribute that can access a MySQL database must be linked against the MySQL library, which is GPL, forcing your application to be GPL.

        Most people don't consider adding MySQL support to their application to be "distributing MySQL".
        • That means that any application that you distribute that can access a MySQL database must be linked against the MySQL library, which is GPL, forcing your application to be GPL.

          No it doesn't. The FLOSS License Exemption [] means that your application is not forced to be GPL if it uses any of 20 of the most popular free software licenses. The exempt licenses include the LGPL, the MIT and BSD licenses, the Mozilla license, the licenses for Perl, PHP, and Python... and the list goes on. In other words, the vast
    • You're right and wrong at the same time.

      Its not that they've restricted the GPL (this doesn't work), its that they relicensed the libraries from LGPL to GPL so that linking against them would cause your program to be GPL'd.

      In the "old days" you could link your proprietary app against the LGPL'd version of the MySQL client and be able to access your database server. Now, since the client is GPL'd, you can't do this.

      I had many discussions on the MySQL users mailing list about the legal restrictions on this,
    • Under the Open Source License, you must release the complete source code for the application that is built on MySQL

      Well, I suppose that is a question of semantics. I would say that if you take MySQL had hack it, relese it as BobSQL, then this applies - BobSQL is built with MySQL. If you write a recepie organizer that uses MySQL, then you need to do nothing.

      Read more about the FLOSS License Exception.

      What is the problem? MySQL has a client library, which is released under the GPL. Generaly, if you wa

    • The key paragraph here is this one:

      * Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not.

      So, unless you actually distribute/modify/copy MySQL, then you are free to do whatever you want with the database.

      This is actually why some of the newer Linux distros don't include a version of MySQL with the's offer
    • It is worth noting that this "highly restrictive license" that they are using is called the "GPL". What the linked page does is just to set some conditions under which you are free of the GPL's requirements for software that incorporates their code.

      Of course, all of the usual provisos stand: the GPL is a license, not an EULA, so you don't have to agree to be bound by its terms to *use* the software (the GPL is quite clear on this).

      All of these issues exist for ANY GPL-covered library code, and all MySQL is

    • Yes, please examine the licence carefully, and you will notice that MySQL is friendly to all major open source licences.

      Thanks to the GPL and our own FOSS Exception, you can mix and match MySQL with other open source software even when the licence texts would otherwise be legally incompatible.

      The only time you need to be aware of our licensing is when you blend some closed source code into the FOSS stew. And for those situations we can offer a commercial licence.

      I think it is fair
  • MySQL 3 - MySQL 5 (Score:4, Interesting)

    by Scoria ( 264473 ) <slashmail@initialize[ ]rg ['d.o' in gap]> on Tuesday September 27, 2005 @09:21AM (#13657656) Homepage
    I certainly have to give them credit for one thing. The MySQL developers have been subjected to some very harsh criticism over the years, but few would accuse them of ignoring it.

    It impresses me that they actually seem to be listening.
    • The MySQL developers have been subjected to some very harsh criticism over the years, but few would accuse them of ignoring it.

      Then why did they dismiss all the criticism in the MySQL 3 manual, even claiming the features make databases more complex and aren't needed? Some of those features are now in MySQL 4.1 and 5 despite their earlier dismissal by MySQL's developers.
  • by Anonymous Coward on Tuesday September 27, 2005 @09:24AM (#13657679)
    Before all the MySQL bashing starts can we please stop and have an intelligent conversation? The bottom line is that MySQL works great! For all those people who say .. "ya its a kids toy" well look at some of the sites and companies that are using mysql.. "Friendster" , "The Friendfinder network" , "Yahoo!" .. These sites each have millions of active members and are running just fine. Where else can you load up a 50+ database cluster and not have to shell out a fortune on licensing fees? All the developer tools are great!!
  • by bogaboga ( 793279 ) on Tuesday September 27, 2005 @09:30AM (#13657718)
    They have done very little about these MySQL gotchas! They should have eliminated most of them first. You can still read them here: [].
    • That list addresses issues in MySQL 4.1 and earlier. Unfortunately I haven't had time to try out any of the MySQL 5.0 pre-release versions, so I'm not in a position to provided any kind of qualified commentary. However my impression is that many of the "gotchas" in the list have been addressed.
    • by minginqunt ( 225413 ) on Tuesday September 27, 2005 @09:59AM (#13657914) Homepage Journal
      No true.

      Those gotchas all (mostly) go away if you run MySQL 5.0 in strict mode. Compatibility mode is provided for 4.1 and back-asswards behaviour if you need it.

      See: html []

  • From []

    Weekly Prize (8 winners; 1 per week) This is your opportunity to win: * An Apple iPod nano To be eligible to win the Weekly Prize, you must: * File reproducible bugs at []

    Reproduc a ble. That's a reproducable bug. iPod Nano with scratchable screen: here I come.

  • by MrBandersnatch ( 544818 ) on Tuesday September 27, 2005 @09:49AM (#13657828)
    is often the better database solution, I'll still be using MySQL. Why? Well a quick search on cwjobs shows 188 jobs requiring MySQL experience vs 7 for postgres!! Its a real shame but having used the best tool (C++ Builder) for my last job and then being unemployed for @2 years because people wanted either VC++ or Unix based C++ experience; I *WONT* be making the same mistake again!

    Anyways, that said, Ive already played about with 5.011 and apart from the yukky syntax one has to use to support transactions it seems quite stable. Its might have taken a long time for them to finally make it a "real" database product but it seems good enough for small databases.

    One of my next jobs is to test it with 10 million + records and see how it performs though so my assessment may be premature...
  • I know that there have been more than a few bashing threads, so I won't add any fuel to them. Props to the mySQL team for adding significant functionality to their software. Triggers and stored procedures are components that are important in making mySQL a production worthy enterprise level product. The big name companies who have been using mySQL likely were using it for basic heavy select statement stuff where inserting or updating recordsets wasn't part of the equation.

    If most of the documented gotchas a

Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry.