Comments on: MySQL Quality of old and new features http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: peter http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-180592 peter Tue, 23 Oct 2007 16:39:43 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-180592 Thank you James. Good to hear it was withdrawn and customer are notified this is indeed the service one should expect if one is paying for. And yes indeed documentation of Regression bug would be very important, though I do not know how it will be available. Thank you James.

Good to hear it was withdrawn and customer are notified this is indeed the service one should expect if one is paying for. And yes indeed documentation of Regression bug would be very important, though I do not know how it will be available.

]]> By: James Day http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-180563 James Day Tue, 23 Oct 2007 15:28:56 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-180563 Peter, because of that order by bug 5.0.48 was withdrawn from availability to Enterprise customers on 13 September, the day it was reported. Each customer who had downloaded it from MySQL was notified of the problem. It still shouldn't have happened but it's the best handling of a post-release problem like this that I've seen so far. For the week or so it was available from MySQL to Enterprise customers 5.0.48 was an MRU and our recommendation for MRUs is that customers only use them if they need a bug fix it contains, preferring the QSP releases otherwise. There's one other change that I'm expecting that you'll probably like: documentation of regression bugs from the version in which we find they were introduced to the version in which they are fixed. Peter, because of that order by bug 5.0.48 was withdrawn from availability to Enterprise customers on 13 September, the day it was reported. Each customer who had downloaded it from MySQL was notified of the problem. It still shouldn’t have happened but it’s the best handling of a post-release problem like this that I’ve seen so far.

For the week or so it was available from MySQL to Enterprise customers 5.0.48 was an MRU and our recommendation for MRUs is that customers only use them if they need a bug fix it contains, preferring the QSP releases otherwise.

There’s one other change that I’m expecting that you’ll probably like: documentation of regression bugs from the version in which we find they were introduced to the version in which they are fixed.

]]> By: she http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175225 she Sat, 06 Oct 2007 04:05:27 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175225 "People will need to realize instead that databases are a horrible idea, which in itself leads to overcomplicated designs and codebases." Oh, i must say this is a WRONG conclusion. The basic and best advantage of a general database is that it can keep ALL your stuff together. I maintained a lot of standalone .html and .php with only very few sqlite3 databases. Although it works, it was not good enough to maintain (i switched to use ruby now anyway, since as a language, ruby is a lot cleaner than php. Which makes it easier for me to maintain it) The database that I now use (mysql... uuugh i know, but the thing was i found a lot more user-contributed tutorials for mysql and sqlite, than for postgre....) keeps the whole dataset and generates "pages" on the fly (with a set of ruby scripts). No more static html pages (and if, then they will be autogenerated) and no ugly php scripts (except for some legacy scripts which i am too lazy to get rid of... but over the years, i think even these will disappear) “People will need to realize instead that databases are a horrible idea, which in itself leads to overcomplicated designs and codebases.”

Oh, i must say this is a WRONG conclusion.

The basic and best advantage of a general database is that it can keep ALL your stuff together.

I maintained a lot of standalone .html and .php with only very few sqlite3 databases.

Although it works, it was not good enough to maintain (i switched to use ruby now anyway, since as a language, ruby is a lot cleaner than php. Which makes it easier for me to maintain it)

The database that I now use (mysql… uuugh i know, but the thing was i found a lot more user-contributed tutorials for mysql and sqlite, than for postgre….) keeps the whole dataset and generates “pages” on the fly (with a set of ruby scripts).
No more static html pages (and if, then they will be autogenerated) and no ugly php scripts (except for some legacy scripts which i am too lazy to get rid of… but over the years, i think even these will disappear)

]]> By: she http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175224 she Sat, 06 Oct 2007 04:02:12 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175224 i think part of this is to blame with MySQL move to corporate levels... which means more looking for new "killer features" and less on the docu+bug fixing parts.... but i think we shouldnt put too much emphasis on it, the base idea is to never become too dependent on one database! i think part of this is to blame with MySQL move to corporate levels… which means more looking for new “killer features” and less on the docu+bug fixing parts….

but i think we shouldnt put too much emphasis on it, the base idea is to never become too dependent on one database!

]]> By: Dan http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175113 Dan Fri, 05 Oct 2007 20:24:00 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175113 For Petri Makinen: What alternative do you have in mind? Because I'd agree with "crappy databases are a horrible idea" but not with that generic statement of yours. For Petri Makinen:
What alternative do you have in mind? Because I’d agree with “crappy databases are a horrible idea” but not with that generic statement of yours.

]]> By: Petri Mäkinen http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175112 Petri Mäkinen Fri, 05 Oct 2007 20:04:52 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175112 People will need to realize instead that databases are a horrible idea, which in itself leads to overcomplicated designs and codebases. Which in turn lead to more horror for clients. Haven't they suffered enough? People will need to realize instead that databases are a horrible idea, which in itself leads to overcomplicated designs and codebases. Which in turn lead to more horror for clients. Haven’t they suffered enough?

]]> By: peter http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175095 peter Fri, 05 Oct 2007 17:53:37 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175095 Indeed Dathan this looks like rather basic bug which was broken in 4.1 which is so old release I would not expect it to happen. Indeed Dathan this looks like rather basic bug which was broken in 4.1 which is so old release I would not expect it to happen.

]]> By: Dathan Pattishall http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175080 Dathan Pattishall Fri, 05 Oct 2007 17:18:06 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175080 There are glaring Serious bugs in production. Any data-corruption bugs that break core functionality like UPDATE should be handled immediately http://mysqldba.blogspot.com/2007/08/oooh-really-bad-bug-in-4123-4124b.html To be honest it's embarrassing. Two years ago, corruption issues would have a special revision and a hosted download of the fixed binary withing weeks if not days. Now well if you have a support contract you will get a special build which is ridiculous. No data corruption bug should make it into a production release-this new don't care policy, conveys that mySQL is a shitty product-to old and new customers alike. In my opinion people who pay money for mySQL should be given piece of mind that mySQL itself will not cause data-corruption. Any updates are to fix non-serious bugs or improve performance. The people want SPEED and Reliability, they will pay for that! To feel confident that mySQL will not cause corruption is to release the fixes and use the community as the testing ground. If it works for the masses then it will work for the specific paying customer. If I where running things; All versions are data-corrupt stable and no Serious bug makes it into production. If so, an immediate release is made. Enterprise has a few optimizations that make it 20% faster then Community (like fix the Optimizer, Grammer Parser, etc). People will pay for Enterprise if they want the speed and support, while the community is happy for a free stable product. There are glaring Serious bugs in production. Any data-corruption bugs that break core functionality like UPDATE should be handled immediately http://mysqldba.blogspot.com/2007/08/oooh-really-bad-bug-in-4123-4124b.html To be honest it’s embarrassing. Two years ago, corruption issues would have a special revision and a hosted download of the fixed binary withing weeks if not days. Now well if you have a support contract you will get a special build which is ridiculous. No data corruption bug should make it into a production release-this new don’t care policy, conveys that mySQL is a shitty product-to old and new customers alike.

In my opinion people who pay money for mySQL should be given piece of mind that mySQL itself will not cause data-corruption. Any updates are to fix non-serious bugs or improve performance. The people want SPEED and Reliability, they will pay for that! To feel confident that mySQL will not cause corruption is to release the fixes and use the community as the testing ground. If it works for the masses then it will work for the specific paying customer.

If I where running things; All versions are data-corrupt stable and no Serious bug makes it into production. If so, an immediate release is made. Enterprise has a few optimizations that make it 20% faster then Community (like fix the Optimizer, Grammer Parser, etc). People will pay for Enterprise if they want the speed and support, while the community is happy for a free stable product.

]]> By: Dan http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175073 Dan Fri, 05 Oct 2007 16:10:36 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175073 Maybe finally people start to realize that MySQL AB is not up to the task, nor their product, regardless of how much they're touting this. This hacker mindset, quick and dirty way, has been long set in their company with foreseeable effects. They are just starting to collect the "rewards" now. I know I shouldn't quite happy about this but given the amount of frustration mysql gave me lately, it's starting to feel a little better to know the company starts to fail so miserably. Maybe things are going to in the right direction though after these problems. Maybe with a complete re-write of the entire MySQL RDBMS, maybe even in java. And maybe they quit this stupid approach of multiple storage engine architecture, which is a complete drag. Once I asked one of their proeminent employee what's the MySQL AB/product position on the market in comparison with the other big players( I had in mind Oracle when I asked that). He answered that "we'll get there". God help that's set to happen in my lifetime. Maybe finally people start to realize that MySQL AB is not up to the task, nor their product, regardless of how much they’re touting this.
This hacker mindset, quick and dirty way, has been long set in their company with foreseeable effects. They are just starting to collect the “rewards” now. I know I shouldn’t quite happy about this but given the amount of frustration mysql gave me lately, it’s starting to feel a little better to know the company starts to fail so miserably. Maybe things are going to in the right direction though after these problems. Maybe with a complete re-write of the entire MySQL RDBMS, maybe even in java. And maybe they quit this stupid approach of multiple storage engine architecture, which is a complete drag.
Once I asked one of their proeminent employee what’s the MySQL AB/product position on the market in comparison with the other big players( I had in mind Oracle when I asked that). He answered that “we’ll get there”. God help that’s set to happen in my lifetime.

]]> By: peter http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/comment-page-1/#comment-175042 peter Fri, 05 Oct 2007 13:02:37 +0000 http://www.mysqlperformanceblog.com/2007/10/04/mysql-quality-of-old-and-new-features/#comment-175042 Heikki, Thank you. I understand. Still over half a year for bug fix is a bit too long. I understand there are design bugs which are extremely complicated, and a lot of such simply were not fixed in given major release, but they often were documented. Bugs like this definitely should have made it to errata so people would know it is known bug which takes a long to get fixed. Heikki,

Thank you. I understand. Still over half a year for bug fix is a bit too long.

I understand there are design bugs which are extremely complicated, and a lot of such simply were not fixed in given major release, but they often were documented.

Bugs like this definitely should have made it to errata so people would know it is known bug which takes a long to get fixed.

]]>