Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Databases Programming Software Sun Microsystems IT

Locating the Real MySQL 335

An anonymous reader writes "In a blog post, Patrick Galbraith, an ex-core engineer on the MySQL Server team, raises the question: "What is the official branch of MySQL?" With Monty Widenius having left Sun and forked off MySQL for MariaDB, and Brian Aker running the Drizzle fork inside of Sun, where is the official MySQL tree? Sun may own the trademark, but it looks like there is doubt as to whether they are still the maintainers of the actual codebase after their $1B acquisition of the code a year ago. Smugmug's Don MacAskhill, who is the keynote at the upcoming MySQL Conference, has commented that he is now using the Percona version of MySQL, and is no longer relying on Sun's."
This discussion has been archived. No new comments can be posted.

Locating the Real MySQL

Comments Filter:
  • by MrEricSir ( 398214 ) on Monday March 30, 2009 @08:03PM (#27395929) Homepage

    This calls into question whether it's viable to sell a business based on open-source software.

    What did Sun buy exactly? Sales and support?

  • Re:PostgreSQL (Score:4, Interesting)

    by LWATCDR ( 28044 ) on Monday March 30, 2009 @08:10PM (#27395999) Homepage Journal

    It really is a very good database. I just hope more projects start using it. And that more hosting companies will as well.
    I am pretty sure that that MySQL still has better client slave replication "Like Slashdot uses" than Postgres. But I could be wrong.

  • Ironic (Score:0, Interesting)

    by Anonymous Coward on Monday March 30, 2009 @08:28PM (#27396189)

    Here we have the one shinning open source alternative to commercial databases and it is now faced with an identity crisis because they sold their name to a company about to be bought by IBM and outsourced to China and India.

    So much for that open source licenses if the many people who worked and contributed all of their time to make MYSQL to make it an enterprise level application get shafted by the few.

    We've seen many terrible forks in the past but this has to take the cake and usually thatâ(TM)s the last you hear of them we all know how well SUN maintains and contributes to there open source projects as it is. It's been awhile but the last time i checked their STL library it was horribly behind. Now imagine IBM.

    Time for postgress, besides it has much better GIS support.

  • Re:Enough already! (Score:5, Interesting)

    by einhverfr ( 238914 ) <`moc.liamg' `ta' `srevart.sirhc'> on Monday March 30, 2009 @08:38PM (#27396279) Homepage Journal

    Actually the subject is how your data is supposed to be used.

    MySQL users see the database as a program persistance layer. I am not sure WHY they are using something that pretends to be a relational database, but they are. It is the single-app approach (one app, one database).

    The PostgreSQL crowd sees data and application as being separate issues. The data in theory should be able to be managed in any of a hundred different applications, all hitting the same database, without causing the nightmares in QA that this sort of thing creates in MySQL.

    So is the program what is important? Or is the data there to be used by many programs?

    MySQL works OK for one-app databases and many people think that is all that is needed. It breaks down outside that area, however.

  • Re:Enough already! (Score:2, Interesting)

    by reiisi ( 1211052 ) on Monday March 30, 2009 @08:46PM (#27396345) Homepage

    Well, we discovered that "elite" is mostly hubris.

  • by jvillain ( 546827 ) on Monday March 30, 2009 @09:02PM (#27396499)

    Actually the message it sends is you can not take control just by buying out one piece of the open source world. For the record Sun is going through the same thing with Open Office. Sun really doesn't understand open source.

    The official branch is where ever the big distros decide to pull from.

  • Re:PostgreSQL (Score:5, Interesting)

    by __aasqbs9791 ( 1402899 ) on Monday March 30, 2009 @09:03PM (#27396505)

    Why do you like it so much? Is it faster with large datasets? Does it support backups/replication/some other great to have feature?

    I'm pretty familiar with MySQL, but I've been thinking about branching out to PostgreSQL lately as I've seen a few jobs that prefer it. I'd just like some real reasons why I should prefer it, as well as any "gotchas" that might be important for a MySQL user to know. I've never had a problem with MySQL, but most of the projects I've used it on have been fairly small.

  • Re:PostgreSQL (Score:5, Interesting)

    by rackserverdeals ( 1503561 ) on Monday March 30, 2009 @09:54PM (#27396913) Homepage Journal

    One of the reasons I like PostgreSQL is it is more like Oracle.

    If you're doing a migration from Oracle, especially one that has a lot of pl/sql functions. Here's some good advice for converting pl/sql to pl/pgsql [redhat.com].

    Also, going from PostgreSQL to Oracle seems easier as well. With PostgreSQL you can use more Oracle like features so if you need to move to Oracle, you can take advantage of some of it's advanced features instead of migrating simple tables and sql statements.

    Sun was actively involved with PostgreSQL before they bought MySQL. I was really dissapointed with their decision, especially at the price.

    My guess is they weren't really buying MySQL for the technology, they were buying it for the community. Overnight, a ton of MySQL users and developers were part of Sun's open source community. Building communities takes time and Sun was having a hard time doing it with some of their projects.

    All it seems they did though is fund MySQL forks. Kinda messed up for the MySQL developers to do that but we don't know all the details.

    $1 billion dollars could have funded a lot of improvements to PostgreSQL better clustering, replication, visual tools, and more. A better PostgreSQL could hurt Oracle more than buying MySQL. After Ellison announced he'd be moving his developers from Solaris workstations to Linux workstations, it could have been a nice comeback.

    It also seems that the switch form solaris to linux might not have been developer driven [intel.com]. Even MS knows you have to keep your developers, developers, developers happy.

  • by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Monday March 30, 2009 @11:09PM (#27397385) Homepage

    There's been plenty of speculation that Sun was interested more in MySQL from the sales side of things than from the technology one. MySQL had figured out how to sell open-source solutions to people for money successfully, something Sun would like to do more of. The high-profile engineers can jump to other projects on a whim, that doesn't necessarily mean they've lost what they wanted out of the purchase.

  • Re:Enough already! (Score:5, Interesting)

    by coryking ( 104614 ) * on Monday March 30, 2009 @11:12PM (#27397409) Homepage Journal

    The RMDBS crowd sees data and application as being separate issues.

    You forgot to broaden your scope. Otherwise, you are correct.

    Your database is almost literally your company. It should reflect your way of doing business--any moderately skilled developer should be able to walk into an orginization they know nothing about and using only the database schema, infer pretty much what the company does, and how it does it.

    You can always fix flawed software design, but it is almost impossible to fix a flawed database design. Do your database wrong, the growth of your company will be hindered. Do it right, and your company will flourish. No joke.

  • *Cough* (Score:3, Interesting)

    by coryking ( 104614 ) * on Monday March 30, 2009 @11:21PM (#27397477) Homepage Journal

    I ran into that little nugget when I migrated webapp database from MySQL to PostgreSQL.

    As with any webapp, the software would let you create an account on the website. Can't have duplicate users, so the code would check to see if the username existed.

    SELECT count(uid) FROM users WHERE username='coryking';

    Got "0"? Well, the user is okay... well, at least on MySQL. In MySQL, "coryking", "CorYKING", and "CORYKing" are all the same. As I would soon discover, that assumption is *not* true on PostgreSQL.

    Result? A month after the migration, I discovered "unique" accounts for "coryking", "CoryKING" and "CORYKING". Obviously, this can't be. All usernames in webland are case-insensitive. Thankfully, there was only a handfull of these "unique" users to clean up. Had this been left alone for a year, I'd have quite a cleanup on my hands!

    Moral? MySQL is case-insensitive, PostgreSQL isn't. Honestly, the proper thing is to be case-sensitive and I assume pretty much every database besides MySQL is case-sensitive. But you have to make your unique index on LOWER(username) instead of username--oh wait, except you can't do that in MySQL cause they dont support indexes on functions... sucks for them!

    Good times.

  • Re:PostgreSQL (Score:2, Interesting)

    by MinistryOfTruthiness ( 1396923 ) on Tuesday March 31, 2009 @09:11AM (#27400773) Homepage Journal

    The "headache" is that it's secure by default and you need to edit pg_hba.conf (allowed IPs) and postgresql.conf (listen port) to get it opened up to the world. In other words, people want it to be insecure, and it takes effort to make it so. Sad that editing a line in two different config files once during the life of a database is now deemed "a headache" and a major reason not to use that database.

    Maybe they're having a hard time finding it in Synaptic? Here's a hint, guys: it's sorted "alphabetically" and there's a search button on the top.

    Otherwise, there are absolutely NONE of the headaches that come with Oracle: the licensing, the immense resource requirements, the bloated platform it brings along with it (several hundred megs for a database?! WTF?) It really is the best of Oracle without Oracle's headaches.

    Oh -- and the killer features for me? ACID, MVCC, plpgsql and plperl, user-defined functions long before MySQL had them, a user and developer community that is second to none, a strong focus on doing it "right"...

  • Re:PostgreSQL (Score:3, Interesting)

    by Eivind Eklund ( 5161 ) on Tuesday March 31, 2009 @11:09AM (#27402373) Journal

    Why do you like it so much?

    It works by default.

    MySQL has, in my experience, a tendency to weirdness. Examples abound:

    • Inserting an invalid value into a ENUM creates an empty string (even if that is invalid for the ENUM)
    • Inserting too long strings leads to truncation rather than an error
    • Inserting empty strings into numbers lead to 0 rather than an error (see a pattern here?)
    • On out of disk, MySQL corrupt indexes (depends a bit on version; newer versions are better)
    • Constraints are not fullfilled by default. To make a true foreign key constraint in MySQL, you have to
      1. Request a special table type (usually InnoDB)
      2. Have the table type enabled on the server (otherwise, MYSQL will silently fall back to MyISAM and not enforce your constraints)
      3. Add the constraint to your table specification
      4. Have a suitable index for use by the constraint, or the constraint will be silently ignored.
    • Replication can silently fail, while looking like it works fine. (This happens when there is a firewall between the master and slave that sometimes drop connections; the slave will believe all is fine even when it does receive any events for weeks.)
    • Subqueries are treated as second class citizens. First they weren't there, then they refused to work in a lot of situations (not allowing the same key used both in the subquery and the outer query), then they had horrible performance for what should be (from the view of the optimizer) simple joins. I think that's still the case, but haven't been involved with query optimization in MySQL for over half a year.

    These are just off the top of my head, and not all that are there. MySQL has way more non-functionalisms. All of the above have impacted development/stability for projects I've been involved in.

    So - I like PostgreSQL because it works. Better performance for complex queries is nice - but I'm mostly interested in the fact that it for the most part just works by default.


  • It isn't fud (Score:3, Interesting)

    by coryking ( 104614 ) * on Tuesday March 31, 2009 @11:44AM (#27402923) Homepage Journal

    It is a bit of lore. It is a difference between the two products that you might not have considered before migrating that you better take into account. I didn't even think about it, and I almost got into a huge jam as a result.

    SELECT count(uid) FROM users WHERE username=BINARY('coryking');

    Except that breaks unicode. Characters aren't byte[]'s, they are characters.

    The proper answer is to use the correct collation. The only thing is PostgreSQL doesn't really do that kind of thing yet.

    My solution was to create a new datatype based on this example [varlena.com] that uses case-insensitive operators. Instead of using the "varchar", I my spiffy new, case-insensitive "ltext" version. Fully indexable too!

The rich get rich, and the poor get poorer. The haves get more, the have-nots die.