#16 2017-08-23 10:50:46

Baba B
Invité

Re: Messages d'erreur suite à upgrade vers la version 2.9.1

ddtddt a écrit:

Bonjour,

user guest est bien toujours présent dans la base de données ?

Oui, je confirme

#17 2017-08-23 13:11:30

ddtddt
Équipe Piwigo
Lieu: Quetigny (21) - France
Date d'inscription: 2007-07-27
Messages: 13777
Site web

Re: Messages d'erreur suite à upgrade vers la version 2.9.1

Bonjour,

Tu peux m'envoyer le lien en MP


Vous aimez Piwigo alors n'hésitez pas à participer avec nous, plus d'infos sur la page "Contribuer à Piwigo". Si vous n'avez pas beaucoup de temps et que vous souhaitez nous soutenir vous pouvez aussi le faire par un don.

Hors ligne

#18 2017-08-23 22:17:58

flop25
Équipe Piwigo
Date d'inscription: 2006-07-06
Messages: 6233
Site web

Re: Messages d'erreur suite à upgrade vers la version 2.9.1

si je peux me permettre, pouvez vous exécutez la requêts Sql suivante dans votre gestionnaire de base de données, sur la base en question

ALTER TABLE `pwg_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false' ;

et pouvez vous aller voir -tjrs dans votre gestionnaire de bdd- les utilisateurs et leurs permissions ? Est ce que l'utilisateur autorisé sur pwg_user_infos a les droits pour effectuer un ALTER ?

Dernière modification par flop25 (2017-08-23 22:21:55)

Hors ligne

#19 2017-08-24 22:32:38

Baba B
Invité

Re: Messages d'erreur suite à upgrade vers la version 2.9.1

Bonjour,

J'ai identifié l'origine du problème: mySQL 5.7 ne supporte pas par défaut les dates avec des valeurs positionnées à "0000-00-00". D'autre part, à chaque mise à jour de structure d'une des tables, mySQL s'assure que cette contrainte est respectée pour toutes les valeurs par défaut et pour les valeurs déjà positionnées dans la table.

Ne souhaitant pas modifier ce comportement par défaut pour mySQL, j'ai donc passé en revue toutes les tables de piwigo et mis à jour les tables contenant des champs au format datetime ou date pour respecter cette consigne.

La migration s'effectue maintenant correctement, la commande d'optimisation également et la page d'édition d'un utilisateur s'affiche.

Ci-dessous, la liste des commandes passées sur la table avant migration. Liste testée avec une base 2.8.0 restaurée suite à la première tentative de migration. Dans le cas de mon site, le préfixe est pwg. A mettre à jour en fonction de votre configuration.

Code:

ALTER TABLE pwg_user_infos CHANGE registration_date registration_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP; 
ALTER TABLE pwg_comments CHANGE date date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_groups SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_history CHANGE date date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE pwg_images CHANGE date_available date_available DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_images SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_old_permalinks CHANGE date_deleted date_deleted DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE pwg_rate CHANGE date date DATE NOT NULL DEFAULT '1970-01-01';
ALTER TABLE pwg_sessions CHANGE expiration expiration DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;
UPDATE pwg_tags SET lastmodified=CURRENT_TIMESTAMP();
ALTER TABLE pwg_upgrade CHANGE applied applied DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP;

Dans le même temps, j'en ai profité pour exporter la base de données dans une nouvelle base avec le bon interclassement et jeux de caractères via la commande SQL suivante.

Code:

CREATE DATABASE pwg CHARACTER SET utf8 COLLATE utf8_general_ci

Quelques informations qui m'ont permis de diagnostiquer le problème et que je n'ai pas trouvées sur le site

  1/ Les scripts d'upgrade se trouvent dans le répertoire install et sont suffixés par le numéro de version. Ainsi, le script install/upgrade-2.9.0.php est lancé pour lancer la migration vers la version 2.9.0.

  2/ Les opérations de migration sont divisées en plusieurs scripts contenus dans le répertoire install/db. Ils sont préfixés par un numéro qui se retrouve dans la table *_upgrade. Les résultats individuels de chacun de ces scripts ne se retrouvent pas dans cette table. Si une erreur se produit, seule la première sera visible dans le fichier d'erreur du serveur web.
  Ces scripts contiennent notamment les requêtes SQL qui sont exécutées pour la migration. Ainsi, la requête suivante mentionnée dans le dernier post levait l'erreur ERROR 1067 (42000): Invalid default value for 'registration_date' si elle était effectuée directement sur la base de données avant migration.
 

Code:

  ALTER TABLE pwg_user_infos
  ADD COLUMN last_visit datetime default NULL,
  ADD COLUMN last_visit_from_history enum('true','false') NOT NULL default 'false'

Après ces investigations, j'ai trouvé un ticket fortement similaire à ce cas. Selon ma compréhension, le problème a été corrigé pour une nouvelle installation de piwigo mais pas (encore ?) pour une migration.
Le ticket est le [Github] Piwigo issue #443 corrigé dans la version 2.8.1 http://fr.piwigo.org/releases/2.8.1.


Bonne fin de journée et merci à tous pour votre aide

#20 2017-08-24 22:39:05

flop25
Équipe Piwigo
Date d'inscription: 2006-07-06
Messages: 6233
Site web

Re: Messages d'erreur suite à upgrade vers la version 2.9.1

[Github] Piwigo issue #670 en fait
je n'avais pas lu mysql 5.7 sur le premier post alors que je connais ces pb Désolé
En fait votre Piwigo est très ancien fait prouvé avec l'interclassement non utf8 : j'ai eu moi même des soucis d'interclassement avec ma très très vieille db

Hors ligne

Pied de page des forums

Propulsé par FluxBB