[Phpmyadmin-devel] bug in MYSQL40 compatibility mode
Hi, I wonder if we should stop to offer the MYSQL40 mode in export, or at the very least display a big warning about it. In this mode, MySQL creates a dump that removes the auto_increment clause for the primary key! Marc Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 358345 to server version: 5.0.21-standard mysql> show create table bug1607282; CREATE TABLE `bug1607282` ( `id` int(11) NOT NULL auto_increment, `description` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 mysql> set sql_mode=MYSQL40; mysql> show create table bug1607282; CREATE TABLE `bug1607282` ( `id` int(11) NOT NULL, `description` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) TYPE=MyISAM
i second that, but then in mode "NONE" there should be an opton "without charset/collations" (similar to "add autoin_crement value") to be able to make dumps targeted at mysql versions prior to 4.1 or mode "MYSQL40" should be silently "repaired". Jürgen (just my 2cent) Marc Delisle wrote:
Hi,
I wonder if we should stop to offer the MYSQL40 mode in export, or at the very least display a big warning about it. In this mode, MySQL creates a dump that removes the auto_increment clause for the primary key!
Marc ---8<---
-- View this message in context: http://www.nabble.com/bug-in-MYSQL40-compatibility-mode-tf2760693.html#a7697... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.
Marc Delisle schrieb:
Hi,
I wonder if we should stop to offer the MYSQL40 mode in export, or at the very least display a big warning about it. In this mode, MySQL creates a dump that removes the auto_increment clause for the primary key!
Marc
Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 358345 to server version: 5.0.21-standard
mysql> show create table bug1607282;
CREATE TABLE `bug1607282` ( `id` int(11) NOT NULL auto_increment, `description` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1
mysql> set sql_mode=MYSQL40;
mysql> show create table bug1607282;
CREATE TABLE `bug1607282` ( `id` int(11) NOT NULL, `description` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) TYPE=MyISAM
is there any bug report about this at mysql? -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel wrote:
is there any bug report about this at mysql?
http://bugs.mysql.com/bug.php?id=14515 http://bugs.mysql.com/bug.php?id=21342 (i have'nt read it yet) -- View this message in context: http://www.nabble.com/bug-in-MYSQL40-compatibility-mode-tf2760693.html#a7698... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.
Jürgen Wind a écrit :
Sebastian Mendel wrote:
is there any bug report about this at mysql?
http://bugs.mysql.com/bug.php?id=14515 http://bugs.mysql.com/bug.php?id=21342 (i have'nt read it yet)
Bug 14515 is relevant. Supposed to be fixed but someone says it's not. Can someone do a quick check, with 5.0.27 ? Maybe we'll have to offer the MYSQL40 option only on MySQL version where it works! Marc
Hi On Tue, 05 Dec 2006 08:15:10 -0500 Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca> wrote:
Bug 14515 is relevant. Supposed to be fixed but someone says it's not. Can someone do a quick check, with 5.0.27 ?
You can try demo, it has 5.0.30 ;-) ... And it keeps auto_increment. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
seems to be fixed in mysql 5.0.27 (on w2k) : -- phpMyAdmin SQL Dump <-- comp mode MYSQL40 -- version 2.10.0-dev -- Generation Time: Dec 05, 2006 at 02:41 PM -- Server version: 5.0.27 -- PHP Version: 5.1.4 -- Database: `abc` -- -- Table structure for table `sessions` -- CREATE TABLE `sessions` ( `sesskey` char(32) NOT NULL, `expiry` int(11) unsigned NOT NULL auto_increment, `value` longtext NOT NULL, PRIMARY KEY (`sesskey`), UNIQUE KEY `exp` (`expiry`) ) TYPE=MyISAM AUTO_INCREMENT=2 ; -- View this message in context: http://www.nabble.com/bug-in-MYSQL40-compatibility-mode-tf2760693.html#a7699... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.
Jürgen Wind schrieb:
Sebastian Mendel wrote:
is there any bug report about this at mysql?
http://bugs.mysql.com/bug.php?id=14515 http://bugs.mysql.com/bug.php?id=21342 (i have'nt read it yet)
ok, so this fixed in released version of 4.1 and 5.0 so, if we add some warning than only for < 5.0.23 / 4.1.21 we should introduce a Class for testing class PMA_Tests { function runAll() { ... } function checkMySqlBug14515() { ... } function checkMySqlBugXXX() { ... } function checkPhpBugXXX() { ... } } so we can have one global place where all test can run (setup script?) and individually places where only one test can be run. using just one generic locale string like 'This action/page is affected by a known bug in your MySQL version. See bugs.mysql.com/XXX' -- Sebastian Mendel www.sebastianmendel.de
Sebastian Mendel a écrit :
Jürgen Wind schrieb:
Sebastian Mendel wrote:
is there any bug report about this at mysql? http://bugs.mysql.com/bug.php?id=14515 http://bugs.mysql.com/bug.php?id=21342 (i have'nt read it yet)
ok, so this fixed in released version of 4.1 and 5.0
so, if we add some warning than only for < 5.0.23 / 4.1.21
we should introduce a Class for testing
class PMA_Tests { function runAll() { ... } function checkMySqlBug14515() { ... } function checkMySqlBugXXX() { ... } function checkPhpBugXXX() { ... } }
so we can have one global place where all test can run (setup script?) and individually places where only one test can be run.
using just one generic locale string like 'This action/page is affected by a known bug in your MySQL version. See bugs.mysql.com/XXX'
Yes it's a good idea. Having a look at what exists currently in PMA, in main.php we do some tests and emit warnings. I would not use the setup script for this kind of warnings, as not everyone use this scripts. In main.php we have specific messages like $strPHP40203 and more general messages used like this: echo '<div class="warning">' . sprintf($strUpgrade, 'PHP', '4.1.0') . '</div>' . "\n"; Instead of the functions you suggested, we could call, at the start of each feature (say, export), a generic function PMA_checkVersion($component, $minimum_version, $bug_number) with the generic message you suggested.
so, if we add some warning than only for < 5.0.23 / 4.1.21 in my tests it works correctly with mysql 5.0.27 but not with mysql 5.0.26. maybe someone can confirm? -- View this message in context: http://www.nabble.com/bug-in-MYSQL40-compatibility-mode-tf2760693.html#a7704... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.
Marc Delisle wrote:
Jürgen Wind a écrit :
so, if we add some warning than only for < 5.0.23 / 4.1.21 in my tests it works correctly with mysql 5.0.27 but not with mysql 5.0.26. maybe someone can confirm?
Where can I get mysql-standard-5.0.26-linux-i686-glibc23 ?
Marc
sorry, i forgot to mention that i did my testing on w2k -- View this message in context: http://www.nabble.com/bug-in-MYSQL40-compatibility-mode-tf2760693.html#a7833... Sent from the phpmyadmin-devel mailing list archive at Nabble.com.
Marc Delisle schrieb:
Jürgen Wind a écrit :
so, if we add some warning than only for < 5.0.23 / 4.1.21 in my tests it works correctly with mysql 5.0.27 but not with mysql 5.0.26. maybe someone can confirm?
Where can I get mysql-standard-5.0.26-linux-i686-glibc23 ?
these releases (5.0.25 and 5.0.26) seem to be removed from any download location and archives ... i don't know if this has something to do with the new MySQL release policy (less releases for community, more releases for enterprise) -- Sebastian Mendel www.sebastianmendel.de
participants (4)
-
Jürgen Wind -
Marc Delisle -
Michal Čihař -
Sebastian Mendel