Truncated incorrect time value

[fourchette]

j'ai une procédure stockée qui effectue une operation telle que

Code :

UPDATE time_reporting_table SET temps = temps + var_temps WHERE id = var_id

Dans cette table time_reporting_table (table de type myIsam), le champ temps est défini comme suit

Code :

TIME NOT NULL DEFAULT '00:00:00'

une fois passée la procédure stockée en prod, j'ai observé sur certains appels l'erreur mysql

Code :

Truncated incorrect time value: '1095:16:32'

Après consultation dans la doc, effectivement la valeur max du type TIME est de +/- 838:59:59
source:

Code :

1
2
3
4
5
6
7
8
9
mysql> SELECT TIME('1000:00:00');
+--------------------+
| TIME('1000:00:00') |
+--------------------+
| 838:59:59          |
+--------------------+
1 row IN SET, 1 warning (0.00 sec)
 
mysql>

Donc si on appelle la procédure stockée en question en essayant d'ajouter 10 minutes alors que la colonne contient par exemple 838:55:59, la somme des deux temps va dépasser le max, donc mysql va être obligé de tronquer à 838:59:59. donc avertissement. etc.

==> jusque là : pas de question.

ce que je ne comprends pas bien, c'est que j'avais bien anticipé cette source d'erreur et j'ai même fait des tests unitaires exposant cette limitation. Or les tests unitaires ne lèvent pas d'exception (la valeur est silencieusement tronquée). Par contre, en prod j'ai une erreur qui a pour effet que l'insertion échoue (pas de temps ajouté) au lieu d’être silencieusement tronquée à 838:59:59

Les droits mysql du user qui crée les procédures stockées, qui les exécute, sont les mêmes en prod et en test.

Code :

GRANT ALL PRIVILEGES ON `madatabase`.* TO 'monuser'@'%' WITH GRANT OPTION

c'est le même nom de user en test et en prod (mais pas le mm server (windows VS linux) + pas la mm version de mysqld et pas le même nom de base)
lorsque je recharge la base de prod dans la base test (en prenant soin de virer les directive DEFINER= de la création de procédure stockée)
==> je répète le comportement en test. à ce stade, si je relance mes scripts de création de procédure stockée sur l'environnement de test, l'erreur disparait à nouveau.
==> même en relançant en prod mes commandes SQL de création de procédures stockées, je n'arrive pas à me débarrasser de l'erreur

j'ai cherché dans les variables de session, qqch qui pourrait expliquer par exemple qu'un warning soit considéré comme une erreur. A l’exception de sql_mode (voir plus bas), je n'ai rien trouvé.
Je viens de repasser toute la faq mysq de dvp sans succès.
J'ai cherché dans le forum, à part http://www.developpez.net/forums/d98...alue-avg-time/ qui ne répond pas à mon problème ==> rien trouvé.

ma question: qu'est-ce qui peut expliquer ce comportement? (troncature silencieusement effectuée VERSUS erreur)

je pense à STRICT_TRANS_TABLES mais dans ce cas, pourquoi le reload des procédures fait disparaitre l'erreur en test mais pas en prod???



qqs info d'environnement
PROD

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
mysql> SELECT version();
+---------------------+
| version()           |
+---------------------+
| 5.0.67-community-nt |
+---------------------+
1 row IN SET (0.00 sec)
 
mysql> SELECT @@GLOBAL.sql_mode;
+----------------------------------------------------------------+
| @@GLOBAL.sql_mode                                              |
+----------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+----------------------------------------------------------------+
1 row IN SET (0.00 sec)
 
mysql> SELECT @@SESSION.sql_mode;
+----------------------------------------------------------------+
| @@SESSION.sql_mode                                             |
+----------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+----------------------------------------------------------------+
1 row IN SET (0.00 sec)

TEST

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
mysql> SELECT version();
+---------------------+
| version()           |
+---------------------+
| 5.1.41-3ubuntu12.10 |
+---------------------+
1 row IN SET (0.00 sec)
 
mysql> SELECT @@GLOBAL.sql_mode;
+-------------------+
| @@GLOBAL.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row IN SET (0.00 sec)
 
mysql> SELECT @@SESSION.sql_mode;
+--------------------+
| @@SESSION.sql_mode |
+--------------------+
|                    |
+--------------------+
1 row IN SET (0.00 sec)

[ced]

Bonjour,

Ton environnement de production est en 5.0, alors que ton environnement de test est en 5.1.
Si tu repasses ton environnement de test en 5.0, est-ce que tu obtiens le même comportement qu'en prod ?

Pour moi, la réponse est très certainement là...

[fourchette]

mmm.. je vais la tenter pour voir.

de tte facon, le moyen le plus simple et le plus sur est tout simplement de cesser d'utiliser un type (TIME) dont je sais que les valeurs limites ne matchent pas avec les valeurs effectivement rencontrées. par exemple utiliser INT et compter des secondes

par contre changer de type va me casser bcp de trucs à coté, je vais avoir pas mal de maintenance sur les tests. mais au fond, tout ca est acceptable. je n'avais qu'à mieux anticiper c'est tout.

ce qui me gene surtout c'est de faire face à une erreur sans pouvoir l'expliquer les différences de comportement. ca ca craint vraiment.

ps: oui je sais c'est pas bien d'avoir des environnements de test & prod différents. je n'ai pas eu le choix c'est tout :'(

[estofilo]

Envoyé par fourchette

ce qui me gene surtout c'est de faire face à une erreur sans pouvoir l'expliquer les différences de comportement. ca ca craint vraiment.

Mais tu l'as trouvé l'explication, c'est sql_mode, pourquoi aller chercher ailleurs?

[fourchette]

Envoyé par estofilo

Mais tu l'as trouvé l'explication, c'est sql_mode, pourquoi aller chercher ailleurs?

si je recharge un mysqldump de prod sur le mysqld de test. (cat backup_prod.sql | mysql bla bla bla)
NB: je passe le dump à sed pour lui virer les DEFINER=bidule sinon j'ai d'autres problemes par ailleurs

==> je reproduis le probleme sur l'environnement de test, malgré le sql_mode vide en test contre mis à STRICT_TRANS_TABLES en prod

1. déjà là je ne comprends pas. pour moi le comportement attendu c'est que l'erreur ne se reproduit pas du tout en test vu qu'il n'y a pas le STRICT_TRANS_TABLES

A ce stade, si je remet toutes mes fichiers.sql contenant les procédures stockées sur mon mysqld de test. (cat script.sql | mysql bla bla bla)
==> le bug disparait en test

2. le comportement attendu serait que ca continue de bugguer vu que les procédures stockées étaient les memes avant et après leur écrasement...

j'y comprends rien