Sun's Mickos Is OK With Monty's MySQL 5.1 Rant 155
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."
Transparency (Score:2, Funny)
If code's too transparent you see right through it to the bloody programmers and their coffee and Monster drinks. In fact, you might see into their dark hearts. You'll see little Guitar Heroes and Battlestar Gallacta action figures. Maybe even, gasp!, some Natalie!
Transparency? Shudder!
Debate? (Score:5, Insightful)
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.
To their credit (Score:4, Insightful)
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?
crashing database == lost data (Score:2, Insightful)
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.
We are in a post-rational debate (Score:3, Insightful)
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
Re: (Score:2)
I work at BIGCO. Everything you say is partly true, but:
I've developed apps on Oracle and MySQL. Cost is not a factor; we get Oracle for free here. And yet I always choose MySQL for new projects. And that is the overwhelming majority preference, among experienced engineers who disagree on lots of other things. Why?
Re: (Score:2)
(like never using a "JOIN" because it mysql is "faster if you give it small SELECT statements).
This isn't entirely accurate. And surely not what MySQL themselves recommend. I attended their high performance tuning class earlier this year and there was extensive talk of using Joins and Table Views in 4.x+ because it *was* much faster. Both are expected to be even more improved in 5.X so they want developers to start using them now.
You really shouldn't blame MySQL for the hordes of new developers who are jus
Re:crashing database == lost data (Score:5, Insightful)
> 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.
Re: (Score:2)
Good to see Rumsfeld invoked to explain databases. It really warms my heart.
If only he had remembered the unknown knowns--the data your DBMS just lost--the set would be complete.
Re: (Score:2)
Donald Rumsfeld, is that you?
http://www.youtube.com/watch?v=_RpSv3HjpEw [youtube.com]
Re: (Score:2)
You most definately can run queries on text files, as various implementations allow it (for example, there's an oledb provider that can do it, some ODBC interfaces, etc). And if you're creative, you could use some distributed transaction system to fake transactions (though I'll admit thats pushing it). Then again, for a large part of its life, MySQL didn't have transactions, no? Good thing they fixed that.
Re: (Score:2, Interesting)
MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random.
I see you've never tangled with FileMaker Pro.
Re:To their credit (Score:5, Interesting)
. (5 insightful???) Well thats kind of harsh.
I've run MySQL datase servers on my websites for nearly 10 years without one problem. Tens of thousands of hits per day. No problems. MySQL is always there, and always working.
I only can wish that my desktop Windows were one-hundreth as reliable.
Re: (Score:3, Interesting)
I've run MySQL datase servers on my websites for nearly 10 years without one problem.
I think the discriminator is the ratio of reads to writes. If it's read-mostly with just a few updates here and there, MySQL can (probably) go a long time without serious data corruption. I would absolutely not recommend it on a site with many update. Slashdot, for example, is in the former category. At say 20 stories per day with maybe 200 posts per story, that's only 4,000 insertions to the comments tables. Since it doesn't allow editing, there are no updates involved. I'll throw in another 10,000 m
Oh great (Score:2)
Next thing you'll say something irritating like 'past performance is no indication of future behavior'.
You guys make me sick, with your logic and stuff.
Re:To their credit (Score:5, Informative)
Sounds like you were using MyISAM. InnoDB will find and detect corrupt pages - and considering that pages get written into the doublewrite buffer, then written to the log, then written to the tablespace, it's fairly unlikely that things end up corrupt without some kind of disk-related issue.
It doesn't auto-repair table because there can be several issues that could cause that to be a bad idea - for example, a broken RAID controller or faulty disk. If your disk is losing writes sporadically (which I've seen happen), then you'll move from a few corrupt records to a swath of corrupt records.
Re: the date thing, the philosophy was that it's not the database's job to validate data. 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. If you really want to limit it to a specific range of dates, then you can tell MySQL that, and you can enforce it in your application (or in a trigger, for that matter).
Your rant would have been very apropos ten years ago; nowadays it sounds like you're just holding a grudge because you don't know how it works or what it does.
Re: (Score:2, Insightful)
Why do I never have mod points whenever MySQL threads come up?! good post.
Re: (Score:2, Insightful)
There is no year 0.
Re: (Score:3, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
Did you at least ask to subscribe to his newsletter? There's nothing quite as exhilarating as expecting the data to be pristine (it is called "ACID" compliance for those of you who've only ever used MySQL) and then some other guy comes along and adds a new method to your model and ... WHOOOPS!
Sorry, Bud. You know all 100,000s of those customer transaction record
Re: (Score:2)
If your app stuck a date of Feb 31st in a customer's record, then your App is to blame. Jeez.
Re: (Score:2)
I tell you what, you feel free to trust the DB layer to do that validation work, and I won't.
We'll see who's happier in the end with the results.
Personally, I like my database code to be intelligent and in one place where it can be debugged as a unit. That means I don't have indexing decisions being made in applications any more than I have text format codes in the database.
Re:To their credit (Score:4, Insightful)
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: (Score:3, Interesting)
I think people are blowing this out of proportion, but in 5 years of using MySQL, I've seen it happen twice.
Once was on a personal site I didn't really care about, the other time was on a site getting tens of thousands of requests an hour. As other people have said, there really is no excuse for dying like that.
Re: (Score:3, Insightful)
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 latte
Hahahah - Toy Database - Hahahahah (Score:2)
Oh, and they shouldn't forget to include the triggers in their custom DB interface. That way they'll know they got it right...until they get it wrong.
Re: (Score:2)
Its interesting how you think a foreign key has anything to do with validating stored data before putting it into a database.
Of course, I know you're just talking out of your alternate orifice to make a point, and more power to you, but yours is completely invalid.
You made no point, and gave no reason as to why validation of dates should be done by the underlying database system.
Do I expect you to use a language or library capable of basic date manipulation when writing software? You bet I do. Do I expect
Re: (Score:3, Interesting)
I've not once had it "blow a table." No doubt that's been your experience.
Here's my problem: the fact that it's even a debating point indicates that it happens way more often than should be tolerated in a database of all things. When people talk about PostgreSQL, they gripe about the (supposed?) lack of replication, but no one complains that they've lost data to it. Same with Oracle: no one loves the price, but it works. SQL Server: hate the lockin, but it works. Even SQLite: not very concurrent, but it works.
That is the reason why I don't recommend MySQL. A database should
Re: (Score:3, Interesting)
Any database can experience data loss. That includes Oracle, SQL Server, and even your beloved PostgreSQL. This can happen for any number of reasons, including (but not limited to) hardware failure, power failure, user error, etc.
Postgres isn't going to help you if you forget a WHERE clause. Oracle isn't going to help you if your RAID is corrupted.
FWIW, I have never had a MySQL database lose data, and I have committed more "user errors" than I'd like to admit. Hell, I once pulled up the wrong window and
Re: (Score:2)
Any database can experience data loss. That includes Oracle, SQL Server, and even your beloved PostgreSQL. This can happen for any number of reasons, including (but not limited to) hardware failure, power failure, user error, etc. Postgres isn't going to help you if you forget a WHERE clause. Oracle isn't going to help you if your RAID is corrupted.
But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center. I'll blame the heck out of it when I get "Table 'FOO' is marked as crashed and should be repaired" for no apparent reason.
FWIW, I have never had a MySQL database lose data
I don't doubt you at all, but my point is that it's happening to some people often enough that people are talking about it. That's wholly unacceptable.
Also FWIW, it is possible to experience data loss with Postgres, where it is Postgres's fault (as opposed to the RDBMS not being able to recover from some external fault). Example 1 [juniper.net]. Example 2 [postgresql.org].
Example one was fixed in 2002. Example two only crops up when you've inserted more than 4Gigarows without the (once
Re: (Score:2)
But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center.
Actually, what you said was "A database should work 100% of the time, for everyone, and discussion should revolve around features or price or support. It should go without saying that it never loses data. That's just not something you should ever even have in the back of your mind.", and I was bringing up those other failure modes to reinforce the fact that you should always have data loss in the back of your mind.
No one is offering you a 100% guarantee that when you put data into your RDBMS, you will neces
Re: (Score:3, Interesting)
I happen to be in a situation where the host system isn't ODBC-compliant so we hosted MySQL on the same box and use custom code to get data out of it. Then I import from MySQL into MS SQL Server. It's very quick for what I do and I haven't had to spend time on maintenance and tuning really like I do MS SQL Server. No table partitioning yet, no manual
Re: (Score:3, Insightful)
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: (Score:2)
Lose. When data goes bye-bye, you lose it. Loose is what your lips are if they're sinking ships.
Re:To their credit (Score:5, Informative)
Nice (Score:4, Insightful)
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: (Score:2)
Full Text Search does not belong in a relational database engine. None of them do it well compared to dedicated FTSE like Sphinx Search or Lucene, not Postgres, not MyISAM FULLTEXT, and not Mssql.
Thus only consider InnoDB for MySQL data storage, it supports transactions, FK support, and safe crash recovery.
Re: (Score:2)
We users of Tsearch2 [sai.msu.su] will vehemently disagree with you.
innodb != fast (Score:2, Interesting)
Sure, innoDB gives you transactions, but at the cost of a lot of MySQL's vaunted speed; half of the reason it took so much of the early open source DB business, lo those many years ago (the other being ease of app development.)
I'm a database rube, but even I've left MySQL for PostgreSQL. Try PostgreSQL, just try it. This isn't your old 7.3 postgres anymore, no siree. ACID all the way, kicks InnoDB's butt and is probably faster than MyISAM most of the time for most of your stuff.
8.4 is nearing completion and
Re: (Score:2)
Re: (Score:2, Informative)
MySQL has all the nice features any commercial enterprise level RDBMS has. The problem is that you can't use them together.
Probably Not Tuned (Score:2)
The default tuning parameters for InnoDB are completely braindead. I don't know why they can't do a better job with that. For instance, the default InnoDB buffer pool size is 8MB. This is woefully inadequate for any nontrivial database operation, because that means your database will only allowed to be able to use 8MB of RAM for data operations.
Have you experienced performance issues with a properly-tuned InnoDB?
Re:Debate? (Score:4, Informative)
Monty went beyond that to suggest that all the company talent was going toward other projects instead of MySQL and that was hurting the quality of the project. So it doesn't seem to be so much about where the quality bar is set and how the company is managed rather than over the existence of bugs. Some of it might be because there isn't a strong enough grasp of how the product is being used to allow for people to make those kinds of value decisions.
More importantly though it's impressive to see a company realize that instead of trying to squelch their development people, letting them say what they want and contribute to the conversation rather than telling them to shut up and get in line is rather impressive. The idea that open source means more than just disclosing code is a key part of becoming a member of the community and it seems like a culture shift in Sun's thinking. Definitely progressive from 5-10 years ago, when this would have been unthinkable.
What terrible expectations! (Score:2)
It's impressive that a company ships junk and admits it? Since when is that impressive? Boy are you setting the bar low.
Re: (Score:2, Informative)
Sun may be more "progressive" than some, but this statement from the article clearly reveals who's running the show:
"...There were still some outstanding critical bugs, and Marketing and Sales were pressing for a release," Maxia added.
This was "understandable," he said. "The economic situation of Sun was not good, the company had just cut 2,500 jobs, and we needed the new release to boost sales.
Seems to confirm the original complaint.
Re: (Score:2, Informative)
Seems to confirm the original complaint.
Please read carefully the next statement in the article.
After that phase, there were a lot of bug fixing before Community and Support agreed to a release. (or read the original article [sun.com])
G.M.
Re: (Score:2)
Re: (Score:2)
It's not debating about a crashing database, but allowing a voice to be heard and not silenced.
There are certainly problems, but there will always be yet another bug no matter how hard you try. And let them be open about it.
If you like ignorance - stick with closed vendors like Microsoft.
What may be debated is if it was pushed into GA too early, and maybe it was. But don't shoot any messengers about that. The real benefits from this is that developers will know more about the issues and can work to solve th
MySQL join performance deficiency, 2 orders of mag (Score:5, Interesting)
Re:MySQL join performance deficiency, 2 orders of (Score:4, Interesting)
I'm not really touching this potato, maybe you're running into some quirks / unfortunate query. Just some quick questions:
- Why don't you have a PK / any index in the address table?
- Did you try a different syntax (e.g. WHERE vs. JOIN ON)?
- Did you try setting different indexes? Tried forcing a specific index?
Re: (Score:2, Informative)
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
The problem with this scenario and why it will always bother people who are used to non-MySQL RDBMS, is that really, you haven't had to think about things like that in a decade (more if you were giving your first born to Oracle).
Equivalent where vs joins should give similar query plans. If not, since the SQL standard where JOINs are first class citizen state that its what you should use for linking tables (no matter how exotic the JOIN), it should handle that better, and having to force an index is usually a crutch (even Microsoft will often consider it a bug, and the logical scenarios get fixed between versions... in 2000 you had to force em every so often, in 2005 they solved most of them, in 2008 I haven't seen an occurance where the analyzer got it wrong...).
The lack of index in the address table is indeed fairly illogical here, but for such a simple query, most RDBMS will be able to do it fine anyway, -especially- with table statistics. In this case, my pragmatic self would never expect it to be fast, but in most RDBMS, it will still be zippy. The only ones I've personally tried that will choke (even with gigs of data) are MySQL and PervasiveSQL (Pervasive makes MySQL look like the holy grail, thats for sure). I've had douzens of databases with up to 50-100 gigs of data (though it was spread out over at least 75-100 tables, sometimes up to a thousand) with no indexes aside for the primary keys and the systems were fast, on MSSQL, Oracle and Postgres (not saying indexes wouldn't have helped a ton, but it wasn't my decision to take), so its a bit of a culture shock to many when you have to spell out your intent to the database that much.
Re: (Score:2)
I take it you're nluv4hs? In that case, if its only 2000 rows, this whole thing should be instant even without index indeed (on an average RDBMS), so this is quite the funny situation
Re: (Score:2)
Ahh ok, my mistake. 10 mins and 45 seconds on 2124 rows? Wow... ok, I take my back previous comments stating PervasiveSQL was worse. I had similar queries (with a few orders of magnitude more rows) on there and I was bitching that it took over 2 minutes, thinking it was insane.
10 minutes and 45 seconds? What is that thing doing? Loading Crysis as part of the query analysis process?
Re: (Score:2)
Yeah, I've seen it... I was mostly just joking. Its such a simple query. I noticed one of the other poster showed a query that actually worked with some changes, but it was far from being a standard query, thats for sure.
Re: (Score:2)
How many records in each table? If both address and range have 2000 records then that is 4M combinations, which it might be running through (and discarding the ones that don't meet the join criteria). That isn't the smart way to do it, but I could see how it could happen.
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
You're probably not going to like this answer but....
The data is not in an optimal form for MySQL. Consider storing the IP address as a BINARY CHAR field, and not as a number. Order the bytes so that it is in big-endian byte order. Now MySQL can use it's indexes.
The problem is that MySQL treats index keys as a binary string so if you are using a function to join two tables, MySQL does things the hard way.
Re: (Score:2)
Re: (Score:2)
Looking at his query I'm not really sure what he's trying to do, but it's a full join without join clause or an index on one of the tables which throws up a few red flags. Whatever the guy was trying to do can probably be done in a much better way.
If MySQL can't do inefficient queries efficiently I don't care. It does efficient queries like the ones that run m
Re: (Score:2)
If you want to sort a bunch of people into different height ranges you usually order them all first and then split them, instead of measuring the height of each person.
Re: (Score:2, Informative)
Having experience with this problem, I can tell you that the problem is that MySQL's implementation of b-tree indices doesn't work well for ranges (specifically, it can only eliminate rows on one side of the inequality). The solution is to use rtree indices (GIS functions, 'SPATIAL INDEX').
I didn't come up with the technique, but I can't find the webpage where I found it. I did end up using it for a geolocation system though.
Re: (Score:3, Informative)
The basic idea is that you create a polygon column and create an entry that corresponds to the start/end points for each row in your table, then you can run a query like this:
SELECT * FROM your_table WHERE MBRContains(polyfield, POINTFROMWKB(POINT(INET_ATON('1.2.3.4'), 0)));
As a point of reference, the above query runs in my local DB here in 0.02 seconds for any IP I can throw at it.
HTH.
Re: (Score:2)
The polygon is a representation of the range in dotted-quad representation of the network address. For example, 3520957440 to 3520958463 (209.221.140.0 to 209.221.143.255).
The table definition is as follows:
Re: (Score:3, Interesting)
Okay... so what's your query?
Re: (Score:2)
How about this one [cmu.edu]? The queries ACID makes (no relation to ACID of DB studies) against the database data generated by Snort are significantly faster in MySQL than Postgresql with certain operations.
PS, that's really old data but I knew where to find it quickly :-).
Re: (Score:2)
PS, that's really old data but I knew where to find it quickly :-).
MySQL doesn't support transactions. I know that's a really old complaint but I knew where to find it quickly :-).
Re: (Score:2)
Except, you're wrong? Transaction support has been in MySQL for many years now. I actually gave a valid performance metric to the questioner.
Re: (Score:2)
Okay... so what's your query?
Postgres is horrible it can't even handle this extremely basic query!
Does anyone ever wonder what.... (Score:3, Interesting)
.
Does anyone remember those Windows 2000 source code comments that leaked a few years back?
We should not punish Open Source for being Open Source. We are a community. OK, more like a family at Thanksgiving, bickering and such.
Re: (Score:3, Insightful)
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".
Not a Problem (Score:2)
I fail to see the problem.
MySQL 5.1 isn't upto snuff, just ditch it entirely and just use Postgre.
Further confirms what we all know: (Score:2)
PostgreSQL is a robust relational database.
Please use and evaluate accordingly.
I'm actually as excited about Drizzle as I am hard on MySQL. MySQL has tried to grow into something it just wasn't designed for. Drizzle is a project to return MySQL to its strengths of being a simple, fast row store with SQL interface. I have no problem with that, I just object to MySQL masquerading as an "enterprise class" RDBMS.
My Experience (Score:2)
I have been using mysql for 5 years(Before that 3 years in Oracle), in hundreds of websites and a few intranets. Some driving huge queries. Some driving simple high volume queries. A few enormous transaction numbers in a few.
I have never had mysql "Blow a table" once, or any other issue, the exception being failing drives.
Re:Uhm (Score:5, Insightful)
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?"
Re:Uhm (Score:4, Interesting)
So tell us, what exactly IS yourSQL?
Re:Uhm (Score:5, Funny)
50% more pretentious, runs all the coolest sites in the world.
Re:Uhm (Score:4, Funny)
If there really was an iSQL it would cost money, decide which SQL statements you wanted to run and how to run them, have no export to other databases but come in a really really flashy box.
Re:Uhm (Score:4, Funny)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Funny)
Uh... I didn't know yourSQL was actually a thing, I was trying to make a joke.
Re: (Score:2)
So tell us, what exactly IS yourASL?
Fixed that for ya.
Re: (Score:2, Funny)
Re: (Score:2)
Only if you pronounce it MySEQUEL.
Re: (Score:2)
Re: (Score:2)
Don't worry, it still doesn't. I'm just trying to rationalise the EPIC FAIL of a joke to stop my brain from exploding :)
Re:Uhm (Score:5, Insightful)
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.
Re: (Score:2, Interesting)
The problem is, MySQL hasn't had a stable, crash-free release in MANY years. The version you think is stable is only stable with your data set and queries.
Re: (Score:2)
In all fairness, I have to comment that I've been using MySQL for all of my projects for years, and I haven't had a crash yet. Because my software is database agnostic I tend to stick to simple inserts, updates, and deletes, and somewhat complex selects. But to date MySQL has been the best open source solution I've come across for flexibility, speed, and ease of use.
Re: (Score:2)
Cue Donald Rumsfeld (Score:3, Funny)
prepare to hear about known unknowns
Re:Same old, same old (Score:5, Insightful)
Except that mySQL is open Source, how can they kill the copy that I have on my hard drive and can re-distribute?
Re: (Score:2)
Oh, they can't take the OLD version away from you. But the NEW version could be completely craptacular. Lack of new features. Slow down development. Don't fix bugs. Half hearted support.
Sure it's open source and other people could do all of those. But if they don't, it doesn't happen. With a business sponsor such as Sun, there are quite a few less people willing to give their effort to ultimately help out a for profit company.
You're a genius (Score:2)
Finally, somebody who can explain when the MySQL binary package installer is broken on a bone-stock Solaris 10 sparc machine.
And, yes, it's totally broken, and yes, I reported it... last year. It simply does not, and CANNOT work unless you chmod a directory in /var/tmp from another window halfway through running.
My God People.
Re: (Score:2)
Re: (Score:2)
Last I checked, they only shipped mysql4 (note -- it's been a LONG time since I've checked).
I use the distribution on mysql's web site. And it is truly broken.
mysql-5.0.51s-solaris-sparc.tar.gz was the one I reported the bug on
mysql-5.1.24-rc-solaris10-sparc.tar.gz was the most recent one I tried.
Re: (Score:2)
You're way off base. Here's what Monty said:
What should Sun have done to make this release better? By the time Sun purchased MySQL, it was already way behind the release
Re: (Score:2)
Isn't it obvious? mysql (the company) sells licenses to use mysql (the software) without having to follow the GPL. Afaict this is thier main revenue stream. To be able to keep doing this they need to make all contributors sign an agreement giving them the right to do this with the contributed code.