MySQL Bugs: #13196: DBD::mysql unable to sense library incompatability after server upgrade

Bug #13196	DBD::mysql unable to sense library incompatability after server upgrade
Submitted:	14 Sep 2005 19:08	Modified:	20 Sep 2005 17:11
Reporter:	Kevin Benton (Candidate Quality Contributor)	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connectors: DBD::mysql ( Perl )	Severity:	S2 (Serious)
Version:	All 4.x and up	OS:	Any (All)
Assigned to:	Bugs System	CPU Architecture:	Any

Description:
DBD::mysql is unable to sense library incompability after upgrading MySQL server.  I believe the best way to handle this is to store the running MySQL server library version when the module is installed, or a list of versions it's compatible with somewhere in the code, then check with the server during the connect() call to find out if the two will work together.  If they won't, then the connect() should fail with a library incompatability error.  Also, if using cpan to install DBD::mysql, DBD::mysql should force itself to rebuild if the SQL server version has changed or at least tell users how to force the rebuild as part of the "already up-to-date" message.

How to repeat:
Upgrade MySQL server but don't upgrade the DBD::mysql module that communicates with the server.  Then, simply attempt to execute a SELECT VERSION() from a perl script.

Suggested fix:
See Description.

added "server" to summary.

I think, the described behaviour:

a) is not a bug - you just request a new feature for DBD::mysql
b) has nothing to do with the MySQL Server at all (but there is no DBD-related category, so let it stay here)
c) surely has not S1 severity.

That is why I changed severity and mark this report as not a bug. I'll file a request for the new category for DBD-related issues.

I completely disagree with the status of "Not a Bug" - the Perl DBD::mysql module (maintained by MySQL folks) does not recognize the difference in MySQL server versions.  This is a severe problem, especially for people upgrading from 3.x to current.  The main problem as I see it, is that DBD::mysql doesn't recognize when the underlying MySQL libraries have changed and reports back (utilizing CPAN) that all is "up-to-date" if the admin attempts to get DBD::mysql recompiled without downloading new code.  This is not very well covered in the installation process (if at all) and creates a larger support issue for people who support code that relies on DBD::mysql, like Bugzilla.

While it's true we can add to our documentation to tell users they must force cpan to rebuild DBD::mysql after a MySQL server upgrade, it really isn't the right way to handle it.  That doesn't help users of other packages like WordPress.  The right way is to get MySQL developers to fix DBD::mysql so it can recognize underlying library changes making it a lot easier for all package maintainers relying on MySQL.

Valeriy - did you know that by setting the status to "Not a Bug" - you've "closed" the issue preventing any changes to the issue except to add comments?

For those of us that rely on the DBD::mysql and associated PHP modules, this is critical to our day-to-day operations.  Unfortunately, we have users that do upgrade the server that don't necessarily know that they also need to upgrade the modules they're using to interact with the DB.  You're right that there's no category for the API (from what I could see) to include interaction with Perl, PHP, C, ... but that doesn't mean it's not a bug or that its severity is any less than Critical.  Frankly, I'm concerned that the modules can't talk to all the server versions backward from the most recently released version as of that date.  I feel it's also important to fix the modules because a server upgrade isn't always done on the same system as where the modules live/reside.

There really ought to be a method for the modules to be able to check server compatability, or at least have the server communicate with the module so they're both talking the same "language."  Until this is done, packages that depend on MySQL are going to continue to have issues.

What module? Did you try to compile DBD::mysql, or do you mean the pre-compiled module from one of the Linux distributions? We don't support those. What we do support is DBD::mysql itself, and the latest version works fine with 4.0, 4.1, and 5.x servers. Just make sure DBI is the latest, then get via cpan DBD::mysql and compile, test, install.

Please list what OS you are using, what distribution, and any other information.

Kevin,

I changed status for you to be able to provide addititonal info requested.

Patrick Galbraith wrote:

> Just make sure DBI is the latest, then get via cpan
> DBD::mysql and compile, test, install.

Patrick - that's exactly my point.  If I use cpan to see if I have the "latest and greatest," and I have MySQL 3.23.x installed locally (as a server), then I upgrade MySQL, if I re-run cpan DBD-mysql, it says I have the latest code and doesn't bother to check the underlying libraries.  The problem is, my module won't work with 4.1.12 until I force the rebuild.  That's a problem - the MySQL module doesn't communicate back to CPAN that it needs to rebuild itself due to a change in the underlying libraries.

I know how to fix the problem.  The problem is, there are a lot of Bugzilla administrators out there that don't necessarily know how to fix it and we're seeing a lot of traffic from users asking us why Bugzilla won't talk to MySQL.  With the 5.0 release coming up soon, I wanted to make sure we get this cleared up *before* goes out and causes others issues due to incompatabilities in the API from version to version.  What's worse is there are a lot of other software admin's that rely on MySQL that aren't as savvy on how things work behind the scenes and wouldn't hesitate to upgrade their MySQL without considering the ramifications.

So, if this is to be fixed, I would hope that the API developers would change the API installation routines so that it can sense a pre-existing installation of DBD::mysql (in this case) and check to see if the underlying libraries have changed.  If not, automatically rebuild even if the latest code is installed.  Or, at least, warn the user that the libraries don't match and strongly recommend they force a rebuild (and give them instructions on how to do that).

Does that make sense?

Jim - thanks for creating the new category, DBD::mysql.  Please consider adding the category "API" and subcategories for each API module, like Perl DBD::mysql, PHP MySQL, Python MySQL, C/C++ MySQL, Other MySQL API, ...

Based on the explanations of severity levels, I have reset the severity on this bug to S2.  I would have set it to S1, however, it only impacts users during an upgrade and shortly thereafter.  Be aware that, after an upgrade, users who fail to rebuild their MySQL API will not be able to communicate with the server.  The workaround to fix this is to force the recompilation of the API until this is permanently fixed.  Note that this does not just affect DBD::mysql.  The PHP module has the same problem, and I would assume other interfaces should be checked as well.

Kevin,

I understand what you're saying, but there is no way for CPAN to know your underlying C libraries. It only checks your perl libraries (DBD::mysql), and if the perl lib is up to date, it doesn't try to upgrade. If you upgrade the C libraries underneath, it's up to you as an admin to recompile and install DBD::mysql against the new C libs, just like any other lib. Take the example of if you upgraded libc or libz, CPAN wouldn't know that either. CPAN deals strictly with the perl side of things. If you change something underneath that's OS level or system library level, you have to delve deeper than CPAN to make it work.

hello,All.

I am an administrator of bugzilla.I met the problem you discussing.That is dbd::mysql is up to date.Would you pls tell me how to issue it ?

I am waiting for your urgent reply,and any help will be appreciated.

kindly pls send email to the below address:
fenghe@engires.net

I'm one of the thousands of admins that are not programmers nor developers who just know enough to follow instructions to install open-source kits such as "RT" help desk software.

I hit the same issue that CPAN reports DBD::mysql up to date, but the application won't work with error shown here:

****************************
cpan[1]> install DBD::mysql
CPAN: Storable loaded ok (v2.15)
Going to read /.cpan/Metadata
  Database was generated on Wed, 19 Sep 2007 22:36:35 GMT
DBD::mysql is up to date (4.005).
****************************

MYSQL dependencies:
        DBD::mysql 2.1018...MISSING

SOMETHING WAS MISSING!