Sun's Mickos Is OK With Monty's MySQL 5.1 Rant

narramissic writes "Back on November 29, MySQL developer Michael Widenius trashed Sun's decision to give MySQL 5.1 a 'generally available' designation in a now-infamous blog post. Widenius warned users to be 'very cautious about MySQL 5.1' because 'there are still many known and unknown fatal bugs in the new features that are still not addressed.' And now we get Sun's response. In an interview Monday, Marten Mickos, senior VP of Sun's database group, said, 'I learned over many years about the benefits and the painfulness of absolute transparency in open source. A little bit of debate never hurts. This is part of being an open-source company. ... People are free to blog about what they want.' Doubtless, this will do nothing to end the debate over whether Widenius will follow fellow MySQL co-founder David Axmark's lead and leave Sun."

Comments

Re:Uhm

[WillDraven]

While I think the AC may be overstating this a bit, I do think the term 'infamous' is being a bit overused here. Ask any random person on the street about this issue and you're probably going to get a response along the lines of "What's MySQL?"

Debate?

[FranTaylor]

What is the debate? MySQL releases with known crashing bugs. Noone is disputing that.

Is the debate over whether or not it is okay to ship a database with known crashing bugs?

It really surprises me to hear someone from Sun saying that one can debate the merits of a crashing database. If this is the expected level of performance from MySQL, no wonder people shun it. At the very least they could have called it a beta or rc release, that would set the expectation level at something approaching reality.

Re:Uhm

[Anonymous Coward]

We use MySQL in a number of critical aspects of our company. I'd rather have a company be honest and let me know I might have some issues with this new release than pretend there are no issues. That lets me stay with my current version and upgrade later.

Rather be on the stable blunt edge in critical infrastructure, not the bleeding edge.

To their credit

[coryking]

MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random. Nothing is more exciting then having a website go down because one of the tables got marked "corrupt" and you have to go "REPAIR TABLE". The damn thing might not even have a load on it and it will blow up!

First of all, what is MySQL doing that corrupts tables during normal operation and second of all? Seriously, a database shouldn't crash like that, ever.

Second of all, it might as well try to auto-repair the damn table. I mean, I've never had it loose data, only somehow decide the table was "corrupt" and then taken offline. And who cares if you do it automatically and it looses data, this is MySQL we are talking about here! They make no claim about data integrity and the user base doesn't even know what that means (must be a car or some "enterprise" feature used only by NASA and Fortune 50 companies)! I mean, 0000-00-00 is a valid date according to them!

But alas, this is MySQL we are talking about here. I mean, it isn't like you are putting any sensitive data on it right? I mean, surely only a fool would use it for anything besides storing data like "number of shoes in my closet" or "number of purses owned by the wife", right?

Good 'ol MySQL. I mean, what fun is a database server that is consistent or predictable?

Re:To their credit

[trawg]

Why do I never have mod points whenever MySQL threads come up?! good post.

Re:To their credit

[wytcld]

Must be in YMMV territory here. I've been running MySQL behind production Web servers for years, through many iterations of MySQL. I've not once had it "blow a table." No doubt that's been your experience. But I have to wonder if it was MySQL that was the weak point in your configuration.

I've found, and reported, bugs in years past. Those were all in peripheral capabilities though, not in basic data handling. MySQL was always good about addressing them. Haven't hit any since Sun took over.

Re:To their credit

[larry bagina]

There is no year 0.

Re:To their credit

[blind biker]

I have been criticizing MySQL for years, because of what I perceived as awful stability. I would be the last one to defend them.

That said, MySQL has never ever crashed for me. Not once. But my usage scenario is one of very light load. That seems still more traffic than "The damn thing might not even have a load on it and it will blow up!", so, maybe (please don't get mad, just an idea, OK?) there is a chance that your configuration is in some way contributing to this?

Re:To their credit

[ortholattice]

You could use -00-00 to refer to an all-year event in some kind of astronomical calendaring system, for example, or 0000-mm-dd to refer to something that happened 2008 years ago.

Wow, I am speechless. This is one of the best attempts to turn a bug into a feature I've seen in years! You should work for MySQL's marketing department. Now I'm really excited to hear about the creative things one can do with Feb. 31st...

Re:To their credit

[MikeBabcock]

I'm sorry, I forgot that many developers expect their storage engine to BE their application instead of writing good code themselves.

Shouldn't you be validating your dates or numbers or other values BEFORE sending them to your storage system? Shouldn't the database's job be to store your data in a logical fashion so its easy to find later, and then find it when you query it?

I don't understand people who expect the database to replace the middleware of their application.

Re:To their credit

[MikeBabcock]

The only time I've blown a table, I did something stupid to the filesystem MySQL was running on while MySQL was still running.

I might add, I've been using MySQL since before InnoDB, when it was a glorified query engine for flat files.

It would seem to me that many developers are lazy and expect their tools to do the work for them. People who complain about some of the little MySQL issues (like date ranges) wouldn't be able to write a working C program with compiler errors disabled.

And yes, I think the latter is valid -- if you depend on the compiler to catch your errors, you're still CREATING errors.

crashing database == lost data

[FranTaylor]

If your database is crashed and is no longer capable of accepting data, how is that different from losing data? Go ahead and explain that with a straight face. Do they have another data store where you can keep your data until the database is fixed?

Sun should be ashamed of themselves for even calling this abomination a database in the first place. The word 'database' carries a whole host of expectations that the product simply does not live up to. A text file makes a better database than MySQL.

Re:crashing database == lost data

[multipartmixed]

> If your database is crashed and is no longer capable of accepting data, how is that
> different from losing data? Go ahead and explain that with a straight face.

Well, for example, losing bank deposits is a lot worse than not accepting them because the database is down. This illustrates why in database land it's important to never lose data, and to always know that the contents of your database is correct.

Or, to explain in more detail...

There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

And the unknown unknowns are most dangerous when it comes to RDBMS integrity.

We are in a post-rational debate

[coryking]

If your database is crashed and is no longer capable of accepting data, how is that different from losing data?

I mean this is mysql here, not a real relational database. Kind of like sloppy cowboy VB coders of yore, MySQL has the same kind of attitude. "If it works, who cares if it is right".

I mean, sure people site "Well, Slashdot, FaceBook, and BIGCO use it, so MySQL is okay". But have those people ever realized how easy it is to lock yourself into MySQL? MySQL is so full of non-standard behavior and gotchas that it can be very painful and difficult to migrate to a real database. So what to companies do? Layer on a huge pile of Memcached and crazy "archive databases" to scale when if they had started with a more standard, scalable database system maybe they could have allocated their developer time to something more productive.

Anyway, I rant. I just think MySQL is only used by large companies because either they don't understand how much extra developer hours are spent working around MySQLisms or they know MySQL sucks, but know that it is to costly to migrate to something better.

But that has nothing to do with your post or my original post does it? I'll conclude with the main problem--Like VB, MySQL grew a whole crop of developers who dont know any better. While I dont know if you can blame that on the database or a programming language, I chuckle when I see MySQLisms in code (like never using a "JOIN" because it mysql is "faster if you give it small SELECT statements).

/Rant Off

Nice

[coryking]

But what happens if you want to do full text search? Besides, your nice ACID InnoDB kinda backfires when half the tables are using MyISAM, doesn't it? And good thing MySQL lets you know when your nice happy transaction will not roll back properly because half the tables are MyISAM, right?

As I said, what fun is a database server that is consistent or predictable?

Re:Same old, same old

[/dev/trash]

Except that mySQL is open Source, how can they kill the copy that I have on my hard drive and can re-distribute?

Re:Does anyone ever wonder what....

[jadavis]

We should not punish Open Source for being Open Source.

But we should criticize it when they unleash bugs onto an unsuspecting public by mislabeling it "GA".