Piwigo Bugtracker

Viewing Issue Advanced Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000137 [Piwigo] database major always 2005.08.16 14:45 2007.02.16 18:16
Reporter Marc77140 View Status public  
Assigned To laurent_duretz
Priority normal Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 1.7.0RC1 Product Version 1.3.2
  Target Version Product Build
Summary 0000137: Crash base de donnée par Packet too large
Description Plus d'affichage des catégories après une mise à jour de la base de donnée.
Voila le diagnostic d'un ami:

ça a été un peu long mais ça y est, les deux problèmes sont identifiés. Le premier, l'impossibilité de mettre à jour la base d'images, est réparé. Il y avait des fichiers images vides. Quand la requête de mise à jour de la base était générée, la syntaxe pour ces fichiers vide était rejetée par MySQL.

Le deuxième problème, la disparition de la liste des catégories, est lié à la taille maxi des requêtes telle qu'elle est configurée sur le serveur MySQL et ça, je ne peux pas le réparer, il faut que ce soit l'hébergeur qui le fasse. Demander à la passer à 4Mo. Explication ici : http://www.nexen.net/docs/mysql/annotee/packet-too-large.php [^]

Ces problèmes sont la conséquence de l'absence de gestion des erreurs qui peuvent se produire pendant la mise à jour de la base dans le code de phpWG. J'ai donc ajouté une détection d'erreur à la plupart des requêtes de mise à jour, ça devrait éviter des problèmes cumulatifs comme ce qui s'est produit ici, endommageant irrémédiablement la base de données.

Le risque que ça se produise sur un site perso est faible car c'est le grand nombre d'utilisateurs inscrits (1686) qui a causé le débordement de taille des requêtes.
Steps To Reproduce
Additional Information Mon hébergeur vient de passer la taille des requètes à 16Mo, et les catégories sont revenues. CQFD
Tags No tags attached.
browser Mozilla
Database engine and version
PHP version
Web server Apache 1.3.x
Attached Files

- Relationships

-  Notes
(0000201)
Marc77140 (reporter)
2005.08.16 18:05

Le problème était:
chaque mise à jour de la base provoquait une disparition définitive de l'affichage des catégories ainsi que des commentaires et noms d'auteur. Aucune validation n'était possible.
(0000212)
plg (manager)
2005.08.18 20:56
edited on: 2005.08.18 20:57

Je met de côté le premier problème lié aux fichiers images vides, pour me concentrer sur le plantage des requêtes car trop grosses.

J'étais d'abord très étonné que cela puisse se produire en 1.3.0 (comme tu l'as indiqué) car ce qui pose certainement problème c'est la fonction synchronize_all_users qui remplit la table user_category, introduite en 1.3.1 pour améliorer les performances (ce qu'elle fait avec succès). Après avoir retrouvé l'adresse de ton site, je conclus que tu utilises en fait une 1.3.2 modifiée (notamment pour la gestion des EXIF).

J'estime que tu as 25 catégories (en regardant ton menu), et 1700 utilisateurs.

L'étude des fonctions admin/include/functions.php:synchronize* et admin/include/functions.php:update_user_category montre :

- un code ultra lourd et complexe, avec 3 ou 4 profondeurs d'appel de fonction :

>.synchronize_all_users
>..|-> get_plain_structure
>..|-> create_structure
>..|-> update_user_restrictions
>..|....`-> get_user_all_restrictions
>..|.........`-> get_user_restrictions
>..`-> synchronize
>.......`-> update_user_category
>............|-> update_user_category (recursivité = horreur)
>............`-> update_uppercats

Au bout du compte, la fonction synchronize execute une requête d'insertion de (nombre de catégories X nombre d'utilisateurs) lignes. Soit dans le cas de Marc77, 42500 lignes. Pour chaque ligne on insère 3 petits numériques et une date. En utilisant les valeurs maximales pour chaque champ, ça donne 24 octets (1 octet = 1 caractère) par ligne. Soit au final une requête d'un peu plus d'1 méga octet. Il s'agit évidemment d'une requête monumentale, mais on est encore loin des 4 ou 16 Mo, à moins que je ne calcule pas correctement.

La bonne nouvelle : depuis la branche 1.4, la table user_category et l'enchevêtrement de fonctions décrit ci-dessus a été supprimé. Je suis revenu à une fonctionnement largement plus simple, et paradoxalement (?) plus rapide. La future/proche branche 1.5 conserve le principe de la 1.4. Sachant que tu utilises un forum + galerie sur ton site, je te conseille vivement de t'intéresser à la future 1.5 qui va te permettre de partager les comptes utilisateurs entre les 2 applications.

La mauvaise nouvelle : n'ayant pas spécialement le temps, je ne modifierai pas la branche 1.3 qui est en passe de devenir la branche N-2.

Marc77 a dit :

> Ces problèmes sont la conséquence de l'absence de gestion
> des erreurs qui peuvent se produire pendant la mise à jour
> de la base dans le code de phpWG

Effectivement, avant la branche 1.4, aucune notification d'erreur en cas de plantage d'une requête. C'est désormais clairement affiché, grâce à la fonction pwg_query (encapsulant mysql_query + affichage des erreurs).

Je tire une leçon de ton problème : il faut mettre en place un garde-fou empêchant la génération automatique de requêtes monstrueuses. A partir de la branche 1.4, c'est uniquement à la fonction admin/include/functions.php:mass_inserts que je dois m'intéresser pour éventuellement découper les insertions en plusieurs paquets.

Merci de nous avoir fait part de ton problème, de ton étude et de sa résolution.

(0001770)
laurent_duretz (developer)
2007.02.16 16:21

la fonction mass_inserts a été modifiée pour récupérer la taille max d'une requête SQL.

- Issue History
Date Modified Username Field Change
2005.08.16 14:45 Marc77140 New Issue
2005.08.16 14:45 Marc77140 browser => Mozilla
2005.08.16 14:45 Marc77140 Web server => Apache 1.3.x
2005.08.16 18:05 Marc77140 Note Added: 0000201
2005.08.18 20:56 plg Note Added: 0000212
2005.08.18 20:57 plg Note Edited: 0000212
2005.08.18 21:01 plg Assigned To => plg
2005.08.18 21:01 plg Status new => assigned
2005.08.18 21:01 plg Resolution open => won't fix
2005.08.18 21:01 plg version 1.3.0 => 1.3.2
2007.02.08 10:44 plg Assigned To plg => laurent_duretz
2007.02.16 16:21 laurent_duretz Status assigned => resolved
2007.02.16 16:21 laurent_duretz Fixed in Version => 1.7.0RC1
2007.02.16 16:21 laurent_duretz Resolution won't fix => fixed
2007.02.16 16:21 laurent_duretz Note Added: 0001770
2007.02.16 18:16 plg Status resolved => closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Contact
Powered by Mantis Bugtracker