[RÉGLÉ] Structure de table ?

[RobertG]

Bonjour,

J'ai un souci d'insertion de données avec un champ vide qui bloque la requête :

INSERT INTO `nj2rg_joaktree_admin_persons` (`app_id`,`id`,`published`,`living`,`page`) VALUES ('13','I121','1','','1');​

Dans la table, le champ n'avait aucune valeur définie. Quand on regarde les anciens enregistrements, ce chqmp "livin est soit 0, soit à 1 et jamais vide. J'ai donc forcé une valeur par défaut à 0 en modifiant la structure, mais la requête me renvoie l'erreur :

Incorrect integer value: '' for column `sql8117_3`.`nj2rg_joaktree_admin_persons`.`living ` at row 1

Pourtant, directement dans phpMyAdmin, cette requête fonctionne sans erreur.

Que puis-je faire ?

[cavo789]

Hello

Tu tentes donc d'affecter une chaîne vide à un champ numérique et c'est non autorisé.

Ce que tu dois faire, c'est de comprendre pourquoi l'instruction insert into utilise '' et non 0. Qu'est-ce qui, dans le code php, traduits l'absence de valeur par une chaîne vide et non, je le présume, 0.

[RobertG]

Merci Christophe, mais dans la mesure où le champ a une valeur par défaut (et que ça ne pose pas de problème en insertion depuis phpMyAdmin), ce champ devrait prendre cette valeur, non ? ce qui est le cas en passant par phpMyAdmin. Et en version J3, ce champ n'avait pas de valeur par défaut (tinyint(1)) et l'insertion d'une chaîne vide se traduisait par "0".

Ce que je ne comprends pas, c'est cette différence entre l'insertion via Joomla! (c'est une fonction core de Joomla! qui génère l'erreur) et celle dans phpMyAdmin.
Cette insertion se fait par lecture d'un fichier texte GedCom issu d'un logiciel de généalogie, et je ne pense pas avoir de prise sur le contenu qui semble géré en lot. En tout cas, je n'ai pas trouvé de fichier où ces données pourrait être manipulées avant insertion.

[cavo789]

Une valeur par défaut est utilisée lorsque le champ n'est pas précisé dans la clause insert into.

Retire living ainsi que '' dans ton instruction et là, la valeur par défaut sera utilisée.

[RobertG]

Je comprends, Christophe, sauf que comme je l'ai dit l'insertion directe de la requête dans phpMyAdmin ne génère pas d'erreur et remplace bien la valeur vide par celle définie par défaut, et que sur le même serveur, et donc le même gestionnaire de base de données (MariaDB 10.6.19) et sans valeur par défaut de ce champ, aucune erreur ne se produit (vérification faite à l'instant) alors que le champ n'a aucune valeur par défaut et ne peut pas être null.

J'ai pu trouver où la valeur est insérée et je l'ai gérée, et je trouve maintenant d'autres erreurs, par exemple d'autres difficultés comprendre comment

if ($ret) { $this->relations->set( 'indNote', true ); }

peut se traduire en indNote = NULL dans la requête... sachant que le champ n'autorise pas NULL et a une valeur 0 par défaut, ou que pour un champ subtype autorisant le null, une erreur bloquante survient pour 'subtype'=NULL dans un UPDATE...

[RobertG]

J'ai beau gérer maintenant toutes les valeurs de indNote de cette manière

if ($ret ===1) {
$this->relations->set('indNote', true );
} else {
$this->relations->set( 'indNote', false );
}        
​

et à d'autres endroits c'était déjà sous forme

$this->indNote = ($result) ? true : false;

Je retrouve une erreur parce que indNote est à NULL dans la requête !

Column 'indNote' cannot be null

string(261) "UPDATE `nj2rg_joaktree_relations` SET `type`='father' , `subtype`=NULL , `family_id`='F107' , `indNote`=NULL , `indCitation`=NULL , `orderNumber_1`=NULL , `orderNumber_2`='1' WHERE `app_id` = '13' AND `person_id_1` = 'I1636' AND `person_id_2` = 'I55'"

[cavo789]

Je comprends, Christophe, sauf que comme je l'ai dit l'insertion directe de la requête dans phpMyAdmin ne génère pas d'erreur et remplace bien la valeur vide par celle définie par défaut, et que sur le même serveur, et donc le même gestionnaire de base de données (MariaDB 10.6.19) et sans valeur par défaut de ce champ, aucune erreur ne se produit (vérification faite à l'instant) alors que le champ n'a aucune valeur par défaut et ne peut pas être null

Mon avis est que phpmyadmin fait du n'importe quoi ici. Il doit y avoir une flopée de warnings qu'il ignore et il fait un truc qu'il ne devrait pas faire.

Ton champ est un entier (un chiffre) et tu lui passes une chaîne de caractères et phpmyadmin ne râle pas ? Euh ???

Puis tu lui affectes une valeur (''), à partir de quel moment va-t-il "silencieusement" refuser la valeur pour utiliser celle qui est par défaut ?

Non, le comportement de phpmyadmin est illicite ici. Je présume qu'il désactive quantité de contrôles auparavant pour autoriser une instruction non valide d'être exécutée.

Pour info, Mysql lui-même autorise du SQL mal formé. J'ai déjà rencontré des cas où syntaxiquement le SQL était faux et pourtant mysql s'autorisait à l'exécuter là où postgresql, plus rigide (ce qui est une qualité) refusait.

[RobertG]

Mais pourquoi MySQL se comporte-t-il différemment entre phpMyAdmin et PHP ?

[cavo789]

Je présume que phpmyadmin désactive des warnings et que Joomla (php) non. Il existe plusieurs instructions de type SET pour cela.

[RobertG]

En tout cas, pour le moment, c'est ce indNote qui arrive null dans la requête alors qu'l est géré à true ou false dans le code...

[RobertG]

J'avance, mais maintenant bloqué avec impossibilité de trouver quelle requête est en cause !

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')' at line 3

[cavo789]

En activant le mode debug de Joomla est-ce que tu ne retrouves pas ce type d'information ?

[RobertG]

Hélas non, c'est bien lui qui me renvoie cette erreur qui est générée dans un fichier du noyau, et un var_dump est inefficace pour intercepter le contenu de la requête. Pour ça, il faut en plus un exit; mais ça stoppe dès la première requête appelée par la page, bien avant celle qui provoque l'erreur.

[RobertG]

Faute de mieux, je crée un fichier texte enregistrant les requêtes mais je ne suis pas fichu d'obtenir un ou deux sauts de lignes après chaque requête (alors que ça ne me pose pas de problème dans d'autres scripts). "\n\n" n'est pas interprété mais reste écrit tel quel...
J'utilise ce code qui enregistre toutes les requêtes jusqu'à la fin

$file_qry = "../query.txt";  // crée à la racine du site
$qury = fopen($file_qry, 'a+');
fwrite($qury, $query);
fwrite($qury, '\n\n');
fclose($qury);​

Le résultat n'est pas simple à lire...

WHERE id = 13\n\nSELECT id
FROM nj2rg_joaktree_themes
WHERE home = 1\n\nSHOW FULL COLUMNS FROM

PS : '\r\n' et '<br/>' ne sont pas traduit non plus

[cavo789]

Pour gérer les sauts de lignes, il faut utiliser les guillemets " et non l'apostrophe.

Remplace donc '\n\n' par "\n\n".

Et oui, faut le savoir.