Différence de comportement entre MySQL de Debian4 et Debian5

Bonjour à tous,

Suite à un crash serveur avec Debian 4 (Etch), j’en ai profité pour passer à la version 5 de Debian.
En remettant mes sites en place je me vois faire face à différents problème que je corrige petit à petit.

Mais le problème qui m’inquiète le plus est en rapport avec MySQL.
En effet entre les deux versions de Debian, la version de MySQL n’est pas exactement la même.
Et bizarrement ( ? ) j’ai notamment repéré la fonction NOW() qui n’est pas exactement la même ! Je m’explique.

J’ai une table comme celle-ci où on peut y voir le champ date_compte de type date et en index unique.

CREATE TABLE IF NOT EXISTS `compte` ( `ID_compte` int(10) unsigned NOT NULL auto_increment, `date_compte` date NOT NULL, `compte` int(10) unsigned NOT NULL, PRIMARY KEY (`ID_compte`), UNIQUE KEY `date_compte` (`date_compte`) );

Pour ajouter une entrée où la modifier je fais cette requête (avec la fonction NOW() de MySQL) :

NSERT INTO compte (date_compte, compte) VALUES(NOW(), 1) ON DUPLICATE KEY UPDATE compte=compte+1;
Pour cette partie tout se passe très bien. Malgré que NOW() renvoi un datetime si la date est la même alors MySQL fait un update.

Cependant là où sa se complique, c’est pour la lecture de donnée à partir du champ date_compte.
Avec la version 4 de Debian je faisais cette requête :

Désormais avec la version 5 de Debian, je me retrouve avec aucune entrée.
Je suis donc pour l’instant obligé de faire comme ceci :

Là où je m’inquiète c’est que je travail pas mal avec la fonction NOW() sur mes différents sites. Ce qui m’oblige actuellement à modifier toutes mes requêtes.

La question que je me pose c’est de savoir si le nouveau comportement de MySQL avec la fonction NOW() est normal où s’il s’agit d’un bug.

NOW()

Retourne la date courante au format 'YYYY-MM-DD HH:MM:SS' ou YYYYMMDDHHMMSS, suivant le contexte numérique ou chaîne :

mysql> SELECT NOW();
        -> '1997-12-15 23:50:26'
mysql> SELECT NOW() + 0;
        -> 19971215235026

ce serait pas une histoire de contexte ?

En réalité la seule différence qu’il y a entre mon champ et ce que renvoi NOW() c’est que mon champ est de type date (2009-08-25) et NOW() renvoi une valeur de type datetime (2009-08-25 14:23:56).
Avec la version de MySQL sur Debian 4 je n’ai jamais eu de soucis. Aucunement besoin de faire le +0 comme indiqué dans la doc de MySQL.
Et là avec la version de MySQL sur Debian 5 sa ne tourne plus de la même manière.

J’ai tout de même essayé en faisant +0 mais le résultat est exactement le même. MySQL ne me retourne aucune ligne.

Je reviens sur mon problème car j’ai bien peur que la fonction NOW() me fasse n’importe quoi sur mes différents sites.
J’aurais aimé savoir s’il est possible d’installer MySQL de la version Etch sur Lenny. Si oui, quelle est la procédure à suivre ?

Tu peux soit compiler les paquets etch sous lenny, soit simplement installer les paquets etch.

N’y a-t-il pas de risque de mettre la version de MySQL de Etch sur Lenny ?
Connais-tu la procédure pour installer la version de MySQL de Etch sur Lenny ?

Le problème réside plus dans l’environnement, les clients mysql de lenny s’attendent plutôt à un serveur 5.0. Il y a également une histoire de locales -mysql a basculé sur UTF-8 pour la version 5.0- bref c’est plus sur l’entourage du serveur que sur le serveur proprement dit. Sinon, les pbms peuvent être les suivants:
Tu as fait la mise à jour et mysql a mis à jour tes bases de données, revenir en arrière peut être problématique sur ses bases, il faut donc prévoir un mysqldump des bases. Je ne pense pas qu’il y ait des difficultés sur le fait de faire tourner des pgms etch sur lenny, la compatibilité ascendante marche bien. Par contre il me semble que le serveur 4.0 est sous sarge pas etch, je me trompe?

Je te remercie pour ta réponse.

La version de MySQL sur Etch est la 5.0.32-7etch10 et Lenny la version est 5.0.51a-24+lenny1.
Les deux sont sur la même branche à savoir 5.0.

A savoir que Etch dispose encore de la version 4.1 donc je pense en effet que c’est la sarge qui a la version 4.0

Et ton serveur avant était un 5.0.32?? Si oui, réinstalle le, il ne devrait pas y avoir de pbm majeur. As tu regardé le fichier /usr/share/doc/mysql-server/changelog.Debian.gz pour voir les changements entre les versions?

J’ai regardé le fichier en question et depuis la version 5.0.32-7 et 5.0.51a-27 et je n’ai vu aucun changement sur la fonction NOW() ou bien même la gestion des dates. :confused:

[quote]Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.0.32-Debian_7etch8-log Debian etch distribution

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> select now();
±--------------------+
| now() |
±--------------------+
| 2009-08-26 18:09:54 |
±--------------------+
1 row in set (0.00 sec)

mysql> select now()+0;
±----------------------+
| now()+0 |
±----------------------+
| 20090826180958.000000 |
±----------------------+
1 row in set (0.00 sec)
[/quote]
puis

Je me demande si ça n’est pas juste une histoire de précision:

[quote]SELECT compte FROM compte WHERE date_compte=NOW();[/quote]a très peu de chances de renvoyer quelque chose, il faudrait que l’enregistrement ait été crée dans la même seconde…

[quote=“fran.b”]Je me demande si ça n’est pas juste une histoire de précision:

Je comprend que tu me dises que ça a très peu de chance de renvoyer quelque chose car il faudrait que l’enregistrement ait été créé dans la même seconde. Cependant le champ date_compte n’est pas un champ de type DATETIME mais de type DATE. Donc non pas un champ de type : 2009-08-26 18:09:54 mais 2009-08-26

Malgré que NOW() renvoi un résultat de type DATETIME, avec MySQL 5.0.32 j’avais un résultat tandis que maintenant je n’ai plus de résultat.

Ok, je vais tester ça pour voir si ça fait une différence.

[code]Your MySQL connection id is 6
Server version: 5.0.32-Debian_7etch8-log Debian etch distribution

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> create database deb;
Query OK, 1 row affected (0.00 sec)

mysql> use deb;
Database changed
mysql> CREATE TABLE compte (
-> date_compte date NOT NULL,
-> UNIQUE KEY date_compte (date_compte)
-> );
Query OK, 0 rows affected (0.01 sec)

mysql> select now();
±--------------------+
| now() |
±--------------------+
| 2009-08-26 21:55:35 |
±--------------------+
1 row in set (0.00 sec)

mysql> insert into compte (date_compte) values ( “2009-08-26”);
Query OK, 1 row affected (0.01 sec)

mysql> select * from compte where date_compte=“2009-08-26”;
±------------+
| date_compte |
±------------+
| 2009-08-26 |
±------------+
1 row in set (0.00 sec)

mysql> select * from compte where date_compte=NOW();
±------------+
| date_compte |
±------------+
| 2009-08-26 |
±------------+
1 row in set (0.00 sec)

mysql> drop database deb;
Query OK, 1 row affected (0.01 sec)

mysql> quit
Bye
[/code]

[code]Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 258
Server version: 5.0.51a-19 (Debian)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> create database deb;
Query OK, 1 row affected (0.00 sec)

mysql> use deb;
Database changed
mysql> CREATE TABLE compte (
-> date_compte date NOT NULL,
-> UNIQUE KEY date_compte (date_compte)
-> );
Query OK, 0 rows affected (0.00 sec)

mysql> insert into compte (date_compte) values ( “2009-08-26”);
Query OK, 1 row affected (0.00 sec)

mysql> select * from compte where date_compte=“2009-08-26”;
±------------+
| date_compte |
±------------+
| 2009-08-26 |
±------------+
1 row in set (0.00 sec)

mysql> select * from compte where date_compte=NOW();
Empty set (0.00 sec)

mysql> drop database deb;
Query OK, 1 row affected (0.00 sec)

mysql> quit
Bye
francois@bling:~$
[/code]

bon, sans commentaire, c’est bien une différence de comportement entre les deux versions. Pétard, ça pourrait être signaler ce genre de choses, pour un changement de version aussi mineur!!

Comme quoi je ne suis pas fou !

Honnêtement je ne comprend pas une telle différence de comportement.
Alors est-ce un bug où un changement de comportement prévu par MySQL ?

J’ai écrit un message sur le forum de MySQL dans la partie Française mais il n’y a toujours pas de réponse.
Je vais essayé de mettre ton log MySQL pour voir s’il y en a qui cerne mieux le problème.

Ce qui me fait le plus peur dans cette différence de comportement c’est que j’utilise la fonction NOW() avec des INTERVAL et les résultats sont eux aussi différents entre la version de MySQL sur Debian Etch et Lenny. C’est pour cela que je n’ai pas encore remis en place les crons de mes sites qui permettent de faire des relances aux clients. Et si un client est relancé ou supprimé alors qu’il ne le faut pas je cours à la catastrophe.

fran.b > Tu as testé les deux versions de MySQL sur Lenny ?
As-tu l’astuce pour installer MySQL Debian Etch sur Lenny ?

signalons, signalons :mrgreen:

mais tu aurais du prendre plus de précaution en comparant deux données qui ne sont pas au même format. ici tu compare YYYY-MM-DD et YYYY-MM-DD HH:MM:SS.

si tu remplace now() par DATE_FORMAT(now(), '%Y-%m-%d') ça devrait marcher sur les deux versions.

Ce que suggère thomas.leclerc est une bonne idée mais nécessite des vérifications.

Pour installer le paquet etch tu fais

C’est bon j’ai la solution.
Après avoir posté le bug sur MySQL j’ai eu la réponse concernant ce fameux changement avec en plus une solution.

La raison pour laquelle ils ont fait ce changement : bugs.mysql.com/bug.php?id=21103

Et ils me conseillent d’utiliser CURDATE() plutôt que NOW() sur un champ de type DATE ce qui semble logique puisque CURDATE() renvoi 2009-08-27.

A moi désormais d’utiliser NOW() à bon escient.

En tout cas je vous remercie pour votre aide :smt058