The obvious follow-up post to the Guide to Incompatibilities when Upgrading MySQL to Version 4.1
is a look at the incompatibilities when moving to version 5.0.

Again, I emphasize the importance of being educated about how upgrading MySQL may affect your application. These are the obvious, flagged items, but I recommend reading all of the 5.0 release notes.

Here are the items from the MySQL 5.0 release notes that are marked Warning: Incompatible change:

• 
  

• C API change: mysql_shutdown() now requires a second argument. This is a source-level incompatibility that affects how you compile client programs; it does not affect the …

I’ve made more improvements to the duplicate index checker. I addressed a MySQL bug Roland Bouman mentioned to me, added more tests to the suite, and made changes so it considers more types of indexes now (HASH, BTREE, SPATIAL). I made no changes to the foreign key checking. The bug Roland mentioned is a problem with SHOW CREATE TABLE that causes MySQL to show an index as type HASH when it’s really a BTREE.

It's been nine months since partition pruning code has been pushed into MySQL 5.1. Another available optimization, partition selection, has been in the main tree for even longer. There haven't been any bugs reported for some time, so the code should be reasonably stable now.

And if you're interested in what's under the hood, a rather detailed description of partitioning optimizations is now available here:

http://dev.mysql.com/doc/internals/en/partitioning-optimizations.html

It is a part of the internals manual, but I tried to write it so it doesn't
require any knowledge of MySQL source code. (and don't be scared away by my English - the text in the manual has passed the scrutiny of the documentation team :)

Hi! My name is Sergey Petrunia and I'm one of the developers in MySQL Query Optimizer team. If you don't have a habit of leafing through the commits list, you probably don't hear much about what we're doing, and we don't have your feedback on it.
This blog is my attempt to rectify this situation a bit. Let's see if it will succeed.

All of the existing PostBuild tests now succeed. So whats next? Developer testing will continue with;

• MS Access (linked tables)
• MS Query
• ADO (via C interface)
• add more PostBuild tests
• respond to QA requests for fixs

At the same time QA folks within the orgnization will start to do their thing.

For folks who are looking at upgrading MySQL to a newer version there is good documentation in the MySQL docs (for example, upgrading from 4.0. to 4.1). My (limited) experience is that folks tend to focus on moving the data between versions, and don't always think about the other ramifications involved in upgrading to a new major version of MySQL.

You'll note that in the upgrade instructions the first step is focused on the behavior of MySQL:

Check the items in the change lists found later in this section to see whether any of them might affect your applications. Note particularly any that are marked Incompatible change. These result in incompatibilities with earlier versions of MySQL and you should consider the implications of these incompatibilities before you upgrade. Note particularly the items under "Server Changes" that …

Hi,

It has been a while since I last posted. We have been busy testing MySQL Cluster, MySQL Replication and MySQL Cluster Replication. Good news is the serious bugs are getting harder to find. This is allowing us to spend some time automating more testing like configuration and up/down grade testing for example.

The documentation guy for cluster, Jonathan "Jon" Stephens, has been doing great work to expand the Cluster on-line manual. If you have not been out there in a while to review you should have a look.

http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html

I feel very positive about this version of the cluster as it has had more hands on testing then ever before. The testing includes: Functional, Negative, Load/Stress, Performance, Recovery, Network Failure, etc...

The new Disk Data will allow customer with huge database to start taking advantage of the …

I fell for it. I commented on the Log Buffer and shortly after that I was offered to host an issue. Here we go, then. Welcome to Log Buffer #12!

Confessions of an IT Hitman by Dratz features a strong message: Don't build a data warehouse, arguing that most of the times a DW is built, it's just because a clueless customers was either listening to buzzwords from a salesman or following the latest trend. The key message, for the ones who missed the build-up of the data warehousing movement during the past decade, is DW is a business solution, not a technology solution. OTOH, there are …

Tomorrow, I have been living a month in Munich. Relocating to Germany brings me closer to MySQL customers, users, and developers. Already, I’ve attended several meetings (OK, still just internal ones) that I wouldn’t have, from Finland.

Looking forward to plenty of interactions with locals, starting from the MySQL Kundenkonferenz Thursday 19.10.2006 here at the Park Hilton, right here in Munich.

Log Buffer #12, a review of the week’s database blogosphere, has been published by Giuseppe Maxia, The Data Charmer. Take it away, Giuseppe!