Discussion :

[Al3x]

Bonjour à tous,

Aujourd'hui j'ai mis en prod un petit CMS développé par mes soins sur un II6/mySQL 5.x/php 5.2.x. Je travaille avec le framework Codeigniter. Mon niveau d'erreur est défini à E_ALL.

J'ai été surpris de voir que PHP me retournait des erreurs en provenance de mySQL sur les types de champs mySQL alors que je ne les avaient dans ma config de développement (LAMP chez ovh).

Je m'explique :

Par exemple,

j'ai un champ "ordre" INT(2) et lorsque que j'envoie une chaîne vide lors d'un INSERT, PHP m'affiche une erreur comme quoi mySQL attends un entier et non pas une chaîne. (Ce que y plutôt normal en fin de compte). Alors que dans mon environnement de développement je n'ai aucune alerte de ce type.

Ce que je cherche à comprendre, c'est quelle est la différence de configuration php ou mySQL qui conduit à ces deux comportements différents.

Bref je voudrais savoir comment afficher systématiquement ces alertes/erreurs afin d'être plus vigilant quant à la définition et au typage des mes champs.

Merci d'avance.

[nosferapti]

montre nous le message d'erreur entier

[Al3x]

je n'ai plus accès au message d'erreur car la machine de prod est dans un extranet...

Mais ce que disait le message php en substance était quelques chose de la sorte :

"Le type fournit pour le champ 'ordre' est incorrect, j'attends un entier"

J'ai dejà vu ce type d'alerte dans phpMyAdmin mais je n'avais encore jamais vu php me retourner ce genre de message lors des INSERT ou des UPDATE.

[pc.bertineau]

Bonjour,

Il y a clairement une différence de config entre les 2 environnements. Dans le fichier php.ini il y a cette clause qui est peut-être activée chez ton hébergeur en PROD :

; Trace mode. When trace_mode is active (=On), warnings for table/index scans and
; SQL-Errors will be displayed.
; http://php.net/mysql.trace-mode
mysql.trace_mode = Off

[Al3x]

Bonjour,Il y a clairement une différence de config entre les 2 environnements.

Merci pour ton coup de pouce !

C'est effectivement ce que je pense, mais il semble, selon le phpinfo qu'on m'avait transmis, que cette option est bien en 'off'.

Y-aurait t il un autre paramètre de config qui pourrait expliquer cet affichage d'erreurs ?

[EDIT]
J'ai mis mysql.trace_mode à 'On' dans ma config de dév et je n'ai pas les erreurs que j'ai vu en prod...

[pc.bertineau]

Alors peut-être regarder du côté de la conf MySql (my.cnf) : niveau de log différent notamment entre ta prod et ovh..

[Al3x]

Alors peut-être regarder du côté de la conf MySql (my.cnf) : niveau de log différent notamment entre ta prod et ovh..

je suis en train d'éplucher les variables mySQL pour voir ce qui pourrait expliquer un différence de comportement de la sorte.

[stealth35]

tu serais pas en mode strict, apres c'est a toi de bien formater les valeurs aussi,
c'est par exemple : WHERE id = 14 et pas WHERE id = '14'
si ton champs est du type int

[Al3x]

tu serais pas en mode strict

comme dit plus haut je suis en E_ALL

apres c'est a toi de bien formater les valeurs aussi,

On est bien d'accord, mais l'idée c'est d'avoir en config de dév un maximum d'alertes afin de me sensibiliser à certaine config de champ un peu "laxiste".

j'ai vu une différence dans la conf, mais je doute que ca soit ca :

dans le dev :
display_errors STDOUT

et dans la prod :
display_errors On

[stealth35]

comme dit plus haut je suis en E_ALL



On est bien d'accord, mais l'idée c'est d'avoir en config de dév un maximum d'alertes afin de me sensibiliser à certaine config de champ un peu "laxiste".

j'ai vu une différence dans la conf, mais je doute que ca soit ca :

dans le dev :
display_errors STDOUT

et dans la prod :
display_errors On

je parle du mode strict de mysql pas de celui de PHP

[Al3x]

je parle du mode strict de mysql pas de celui de PHP

oops :-)

Ca me semble pas mal du tout comme piste ca !! je vais investiguer dans ce sens...

[Al3x]

Bingo !

Merci stealth35, le mode SQL était bien : STRICT_TRANS_TABLES !