[RÉGLÉ] Erreur en màj de champs de la BDD

[Visiteur]

Mon environnement : Joomla 3.8.6, php7.0.30, Apache 2.4.18, CB 2.1.4, développement en localhost

Avec les dernières versions de Joomla, quand je veux modifier la structure d'un champ de la BDD (par phpmyadmin), la tentative d'enregistrement se termine systématiquement par le message d'erreur :

--> Invalid default value for 'message_last_send' !

et la sauvegarde avorte.

nb : 'message_last_send' est un champ de type DATETIME pré-établi de la table xxx_comprofiler de CB

J'ai beau tenter une modification de cette valeur par défaut parmi les options proposées, rien ne fonctionne.

Quelle solution pérenne faut-il donc appliquer ?
D'avance, merci pour votre aide.

[roland_d_alsace]

Hello.

Il faut autoriser le default à zero pour les champs date dans la configuration de mysql ou de mariadb.

voir : https://ordi-genie.com/developpement...ration-de-wamp au paragraphe Erreurs lors de l'import MySql / incorrect datetime value '0000-00-00 00:00:00'

[Visiteur]

Merci beaucoup Roland . Malgré bien des recherches sur Google, je n’avais trouvé aucun piste correctrice.
J’essaierai demain d’appliquer ce correctif dans Mysql.

[Visiteur]

Les conseils de roland_d_alsace étaient fort judicieux. Mon problème est solutionné.
Pour les appliquer dans un environnement 32 bits, il faut modifier le fichier de configuration :

--> /etc/mysql/mysql.conf.d/mysql.cnf

et y ajouter le bloc :

[client]
sql-mode="STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"

[mysql]
sql-mode="STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"

[ZerooCool]

Je ne sais pas ce que vous en pensez, mais, on m'avait dit récemment que le forum est plus dédié à l'usage de Joomla que à son administration serveur.
Pourtant, on remarque bien que pas mal de messages pourraient aller dans un forum " Gestion serveur ".
En tout cas, merci pour le partage de cette configuration de MySQL pour Joomla!

Faut t'il que j'inclue ce bloc par défaut, lors de mon installation de Joomla standard ?
J'ai fais ce petit script, pour installer Joomla sur un serveur Apache2 MariaDB, mais, je n'ai pas intégré vos lignes, donc, si c'est important, il faudrait que je le fasse.
Installer le serveur : https://github.com/ZerooCool/Linux-S...e-conteneur.sh
Installer Joomla : https://github.com/ZerooCool/Linux-S...ller-joomla.sh

D'ailleurs, est ce un problème propre à Joomla, ou bien, un champ date sous Wordpress, via PHPMyAdmin, aurait créé la même erreur ?

[ZerooCool]

Ce soucis de date et de configuration serveur m'a intrigué, alors, j'ai fais un tour sur la communauté de Développez, dans le chat dédié aux bases de données.
Voilà l'échange que j'ai eu avec Lyche, le modérateur du chat pour la thématique sur les bases de données.

J'espère que le copier coller n'est pas trop lourd, mais, j'ai trouvé sa réponse intéressante.

17:22 [ZerooCool]: Faut t'il appliquer cette configuration à tous les serveur, par défaut ?

17:25 [Lyche]: Une date type 0000-00-00 ça n'existe nullpart ailleurs que chez MySQL. Donc pour compenser ses bonnes blagues des valeurs improbables, on invente des paramètres à configurer pour compenser.

17:25 [Lyche]: je suis pour "soit la date est null, soit la date est valide", par pour des dates inexploitables par autre chose que MySQL

17:29 [Lyche]: Le souci est qu'en modifiant son champ, MySQL tombe sous le coup d'une erreur inhérente à son type dateet qui, n'était pas géré par la configuration de MySQL/MariaDB en effet.

17:30 [ZerooCool]: Du coup, quand j'installe un serveur mysql / mariadb par defaut, tu me conseilles de modifier la configuration comme proposé ?

17:30 [Lyche]: donc oui, si tu sais que ton serveur peut tomber sur ce cas de dates à 0000-00-00, alors pense à configurer ton serveur

17:30 [ZerooCool]: Si j'ai bien compris ta réponse, il faudrait utiliser NULL, pour des dates non renseignées.

17:30 [Lyche]: Je pense que c'est une question d'affinité personnelle. SQLPro te dirais que si ton champ peut-être NULL c'est que ton modèle a un défaut.

17:31 [ZerooCool]: Ce serait donc propre à community builder dans cet exemple, qui utiliserait alors des 0000-00-00 au lieu de NULL

17:31 [Lyche]: Je pense qu'une date PEUT être NULL dans certains cas (une date de fin par exemple)

17:31 [Lyche]: et donc, oui, si tu sens que tu auras besoin de cette configuration, fait le (ça t'évitera peut-être des plantages en cours de process )

17:31 [ZerooCool]: ok oui, je vois, pour le modèle, NULL, car, pas de date de fin définie, donc, la durée est illimitée.

17:32 [Lyche]: c'est ça, et puis, le format NULL est prévu pour être traité par SQL de façon simple "IS NULL" "IS NOT NULL"

17:33 [ZerooCool]: Bah, je me demandais si c'était une configuration " type ". En fait, tu me dis que ce qui a posé problème ici, c'est un mauvais modèle de Community Builder, car, ça aurait du fonctionner, avec une configuration par défaut, qui aurait du peut être utiliser NULL plutot que 0000-00-00

17:33 [Lyche]: c'est ça. à l'origine le souci viens de la configuration initiale de MYSQL.

17:34 [ZerooCool]: Peut être que quelqu'un va réfléchir à faire remonter ça à community builder.

17:36 [Lyche]: en fait, c'est un bug sans être un bug

17:36 [Lyche]: c'est à dire que c'est un processus par défaut de MySQL.

17:37 [ZerooCool]: Oui, c'est un soucis de CB, qui a des valeurs qui ne sont pas comprises par mysql si je comprend bien, de ce fait, phpmyadmin ne peut pas modifier la struture des tables.

17:37 [Lyche]: c'est ça, si tu as une valeur que le type ne supporte pas, bah.. il va pas être content si tu modifies le type

17:37 [ZerooCool]: En fait, on triche sur le serveur, alors qu'on aurait du adapter community builder.

17:38 [Lyche]: C'est exactement ce que je pense de l'open source, c'est à dire qu'on triche sur pleins de choses pour cacher des bugs.

[roland_d_alsace]

Ce soucis de date et de configuration serveur m'a intrigué, alors, j'ai fais un tour sur la communauté de Développez, dans le chat dédié aux bases de données.
Voilà l'échange que j'ai eu avec Lyche, le modérateur du chat pour la thématique sur les bases de données....

Salut Bernard, bien rentré Samedi dernier ?.

Pour te répondre, le zéro dans les dates ne concerne pas que CB, mais Joomla et la plupart des composants.

Si tu regardes dans la structure de la DB de Joomla la plupart des rubriques de type datetime est bien initialisé à zero (voir /installation/sql ou avec phpmyadmin).

  `checked_out_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
....
  `created_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
....
  `modified_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',

La config de base de MySql a changée il y a quelques version (je ne me souvient plus vraiment laquelle).
J'en ai parlé sur le forum à l'époque et j'ai mis l'info sur mon site (lien donné en réponse à cette discussion...)
où j'indique qu'il faut supprimer le NO_ZERO_DATE dans la variable sql-mode du my.ini

Toutefois la discussion que tu rapportes me parait très incomplète, et peut être mal interprétée (je ne connais pas ton interlocuteur, mais certaines réponses me laissent perplexe, la dernière surtout...).

Le fait qu'il y a des dates à zéro dans Joomla ne peut être considéré comme des bugs.

Attention aussi au fait que :

• Le NULL est un état qui indique que la rubrique n'est pas renseigné, il n'a aucun rapport avec zéro.
• NULL réagit différemment dans les conditions de requettes qu'une valeur (y compris zéro).
• Les valeurs NULL et '0000-00-00' dans les dates ne sont donc pas identiques !

[ZerooCool]

En fait, j'ai cru comprendre en échangeant avec Lyche, qui me disait "Une date type 0000-00-00 ça n'existe nullpart ailleurs que chez MySQL." qu'il aurait été préférable d'utiliser un format plus compatible, et, qui soit reconnu par défaut, sans devoir modifier la configuration du serveur MySQL.

A son commentaire "SQLPro te dirais que si ton champ peut-être NULL c'est que ton modèle a un défaut." je me suis dit que peut être CB, voir Joomla!, avaient à améliorer cette question de date à 0000, puisque, même si je comprend son utilisation " La date n'est pas renseignée " elle est alors définie avec des 0000 ce qui ici crée ce besoin récent de paramétrage supplémentaire pour MySQL.

J'ai pensé que NULL pouvait être une solution plus adaptée mais surtout qu'il serait intéressant de voir si ce date type à 0000 pourrait être amélioré pour ne plus avoir besoin de modifier l'installation standard de MySQL.

Les valeurs NULL et '0000-00-00' dans les dates ne sont donc pas identiques !

Oui.

Quoi qu'il en soit, j'ai pris en compte cette configuration dans mon script d'installation pour un serveur web.
Je l'ai laissé en commentaire, en précisant qu'il s'agit d'une configuration pour Joomla et également pour le type date à 0000.

Je me demande tout de même si cette configuration de MySQL peut impacter négativement les besoins d'un autre outil qui pourraient avoir besoin du NO_ZERO_DATE et NO_ZERO_IN_DATE.


Pour conclure sur une proposition qui pourrait être fonctionnelle, au lieu d'afficher la valeur 0000-00-00 quand une date n'est pas renseignée, il suffirait de sélectionner par exemple 0001-01-01.
Évidement, aucun article n'est écrit le 1er janvier de l'an 1.
Au lieu d'afficher alors 0000-00-00 dans le champ date, depuis un article par exemple, une ligne de code pourrait analyser que si 0001-01-01 est présent, il faut afficher " Date non définie ".
Ainsi, plus de soucis avec les dates nulles. Plus de soucis avec le type 0000-00-00 qui n'existe que chez MySQL, plus de date 0000-00-00 affichée en front ou en back end quand la date n'est pas renseignée. Un message en français afficherait à la place : " Date non définie ". La valeur enregistrée en base pourrait être standardisée pour Joomla, à 0001-01-01.

Bénéfices ?
- Une installation standard et une configuration standard pour MySQL.
- Une éventuelle compatibilité avec une autre base de données ?
- Ne plus afficher l'information 0000-00-00 quand une date n'est pas renseignée, mais, un texte " Date non définie " / " Date à renseigner ".
- La valeur stockée en base ne serait plus 0000-00-00 mais 0001-01-01 ?
- Et beaucoup de travail pour la communauté qui devrait tout mettre à jour.

[roland_d_alsace]

J'ai pensé que NULL pouvait être une solution plus adaptée mais surtout qu'il serait intéressant de voir si ce date type à 0000 pourrait être amélioré pour ne plus avoir besoin de modifier l'installation standard de MySQL.

Comme dit le comportement du moteur de SGBD est différent :
Par exemple une requete SQL sur un champ date ne retourne aucune réponse si la valeur dans l'enregistrement est null alors qu'il retourne les enregistrements de valeur 0000-00-00 s'ils sont dans la plage demandée.
Ceci comme n'importe que autre type de champ (numérique par exemple) ayant soit une valeur zéro, soir null.

Le fonctionnement est donc homogène quel que soit le type du champ.
Il est possible que cette option maintenant forcée à NO_ZERO_DATE soit imposée par la norme SQL, mais comme indiqué plus haut le zero reste intéressant.

La solution que tu proposes est déjà implémentée par Joomla, comme tu pourras le constater dans le dossier d'installation de joomla :
- pour postgress qui utilise les timestamp la date par défaut est bien 1970-01-01 (valeur zéro d'un timestamp Linux)
- pour sqlazure 1900-01-01

Tu vois donc que chaque moteur de DB a sa spécificité.

En production, il semble qu'en général les hébergeurs aient choisi de conserver cette valeur zéro pour mysql, vu que de nombreux développeurs l'utilisent et que historiquement c'est la valeur minimale d'une date).

Il n'y a guère que si tu installe toi même mysql qu'il faut vérifier le configuration, mais en général c'est ce que l'on fait, car il y a d'autres paramètres à changer ou à vérifier (comme au minimum l'emplacement des conteneurs innodb ou des fichiers myisam, etc...),.