🌍
Français
Patrice, tu vas te faire disputer par les modérateurs du forum pour ne pas avoir ouvert de nouveau sujet ;-D
Pour la synchro, tu peux déjà passer le max_execution_time à 0 pour avoir un temps infini.
Pour la synchro, tu devrais diviser en site (c'est à en dire en répertoire).
D'abord un grand merci à rvelices et à rub pour les essais qu'ils ont faits pour comprendre ce qui n'allait pas dans la base SQL.
rvelices a écrit:
changer le type de la colonne forbidden_categories de TEXT a MEDIUMTEXT avec la requete :
Code:
ALTER TABLE phpwwbgallery_user_cache MODIFY COLUMN forbidden_categories MEDIUMTEXT DEFAULT NULL
Il faut écrire :
Code:
ALTER TABLE phpwebgallery_user_cache MODIFY COLUMN forbidden_categories MEDIUMTEXT DEFAULT NULL
rvelices a écrit:
- obliger pwg de recalculer les permissions avec la requete :
Code:
UPDATE TABLE phpwwbgallery_user_cache SET need_update=true
Il faut écrire (correction proposée par rub):
Code:
UPDATE phpwebgallery_user_cache SET need_update=true
J'ai exécuter ces 2 requêtes qui ont corrigées le problèmes d'afficher les photos privées sans être identifié.
L'utilisation des Tags, Flat (icone étoilée) et le calendrier n'affichent plus les photos privées sans identification.
Le problème de lenteur du site hébergé sur mon PC, n'est pas trop grave vue que j'ai prévenu les utilisateurs qui ne se plaignent pas,
mais pour moi c'était un grand souci depuis la mise en place de mes nombreuses photos.
Sur l'hébergement distant il y a également le pb du time-out Apache (pour être tranquille lorsque que je fais la synchro, je l'ai mis à 3600 !!!), c'est pour cela que j'ai choisi l'option hébergement sur mon PC.
rvelices a écrit:
merger ensemble tous des repertoires du style 001, 002, 003 etc..
Les sous catégories 001, 002, etc.. représent un acte (exemple inventaire et partage du 11-08-1662) variant entre 1 à 100 pages, il vaut mieux ne pas faire un merge, le choix de l'acte pour une certaine date sera pas facile à sélectionner.
Merci à cette formidable équipe de PWG.
Patrice
patnoe a écrit:
Certains Tags sur les Photos Privées sont visibles par tous les utilisateurs
Le probleme de permissions n’est pas lie aux tags (les vues calendrier / images recentes ou flat posent le meme probleme). Voila l’explication et une solution :
On calcule pour chaque utilisateur la liste des identifiants des categories qui sont interdites. Cette liste est sauve dans la table phpwebgallery_user_cache, colonne forbidden_categories. Cette colonne est de type TEXT, ce qui veut dire que la longueur du champ est limite a 64 Koctets. Le guest a acces a une dizaine des categories sur presque 29000 categories. La liste de approx. 28890 categories restantes depasse largement 64K, donc MySql va tronquer cette liste a 64K. Pour cette raison, le guest peut acceder a toutes les categories qui sont a la fin de la liste.
La solution immediate :
- changer le type de la colonne forbidden_categories de TEXT a MEDIUMTEXT avec la requete :
ALTER TABLE phpwwbgallery_user_cache MODIFY COLUMN forbidden_categories MEDIUMTEXT DEFAULT NULL
- obliger pwg de recalculer les permissions avec la requete :
UPDATE TABLE phpwwbgallery_user_cache SET need_update=true
Maintenant je trouve que le site est tres llllleeeennnnttttt notamment a cause de la taille de la base. Clairement certaines fonctionalites (comme calendrier ou vue flat) ne seront pas utilisables a cause de la lenteur (certaines prennent jusqua 40 secondes). En plus ce qui marche sur ton PC, risque de ne pas marcher sur un hebergement web classique car les scripts sont trop consomateurs de CPU.
Voici pour commencer 2 idees pour ameliorer les perfs :
- reduire le nombre de categories : 29000 c’est vraiment trop pour PWG. C’est ici que tu vas gagner le plus en perfs. Je ne sais pas si c’est possible pour toi (il doit y avoir beaucoup de travail), mais merger ensemble tous des repertoires du style 001, 002, 003 etc… ferait une grande reduction en nombre de categories.
- choisir manuellement pour les categories qui contient seulement des sous-categories une vignette representante. Sinon PWG va essayer de chercher une vignette d'une maniere recursive pour chacune des sous categories. Par exemple sur la page principale je vois 41 sous-categories et 99% du temps sql est passe pour chercher ces vignettes.
boudiou encore une maxi (pwg)gallerie :)
Probléme affichage des Tags résolu.
J'ai mis en place la fonction corrigée par rvelices voir http://bugs.phpwebgallery.net/view.php?id=736 functions_tag.inc.php r2087.
Tout ce passe bien, plus d'erreurs.
Je remercie rvelices pour son efficacité et bien sûr mes remerciment à toute l'équipe.
****************************************************************************************
J'ai commencé à mettre des Tags en place, mais hélas un autre problème est apparu.
Certains Tags sur les Photos Privées sont visibles par tous les utilisateurs
Après plusieurs test sur ma base photos archives avec un Tag test1
Sur les photos avant (partie du chemin) : /102805/category/3766/ ne sont pas visibles par les utilisateurs non identifés , ce qui est normal.
les photos à partir de /102806/category/13257/ sont visibles par les utilisateurs non identifés , ce qui n'est pas souhaitable.
Si un des développeurs à besoin d'un login et mot passe, me le faire savoir par mail, merci.
NB. la base augmente
Base de données
380710 éléments (premier élément ajouté le Dimanche 19 Août 2007)
28969 catégories dont 28969 physiques et 0 virtuelle (380710 associations)
1 tag (22 associations)
16 utilisateurs
5 groupes
0 commentaire
En attendant je ne me soucis pas du pb des Tags, j'en utiliserai pas en attendant.
Je pense que vous êtes de très bon développeur et vous trouverez une solution.
Je vais limiter le nombre d'utilisateurs, pour ne pas charger ma bande passante.
En fin d'année j'aurais 400 000 photos d'archives anciennes, la base va gonfler régulièrement, objectif le plus possible.
Les personnes qui utilisent mon site, font uniquement la transcription et ou la traduction des actes, quelques uns vont utiliser les photos pour illustrer leurs publications.
Cela fait de nombreux mois que je cherchai un prog. simple (moins compliqué que le Coppermine, installé sur un de mes site avec quelques photos), et je pense que j'ai trouvé mon bonheur avec PWG.
Les miniatures et les photos en taille réelles (1696 x 2544) sont suffissantes pour l'affichage et la lecture des actes.
VDigital a écrit:
J'ai bien compris... Reste que
WHERE image_id IN (669, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 683, 684,
685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 89238, 89239, 89240, 89241,
................................
................................
dépasse les 2.7Mo
8-)
On ne devrait jamais arriver à ca.
Pour moi, c'est que ca pèche de notre côté.
rvelices a écrit:
rub a écrit:
Une solution simple et rapide est de passer par la table #cache et par jointure.
Le seule endroit ou ce n'est pas applicable c'est lors de l'alimentation de la table #cache mais il y a plusieurs méthodes pour le faire.Je suis pour laisser MySql se debrouiller ... Il y a des chances qu'il optimise bien les requêtes ...
Tout à fait ce que je pense.
Pour l'instant, on va corriger le pb des tags mais après il y aura sûrement d'autres surprises. (comme celui cité par VDigital).
Il faudrait qu'on arrive à avoir soit en local en dev ou en démo/test sur le net une big-big base de données! Pour les images, on aura les sites distants (même avec des liens).
Le soucis pour un big-big base, c'est la place! Celle de patnoe ne fait que 90 Mo pour le moment!
Une nouvelle base sur le même serveur que la démo serait possible?
Ce n'est pas faux...
8-)
rub a écrit:
Une solution simple et rapide est de passer par la table #cache et par jointure.
Le seule endroit ou ce n'est pas applicable c'est lors de l'alimentation de la table #cache mais il y a plusieurs méthodes pour le faire.
Je suis pour laisser MySql se debrouiller ... Il y a des chances qu'il optimise bien les requetes ...
J'ai bien compris... Reste que
WHERE image_id IN (669, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 683, 684,
685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 89238, 89239, 89240, 89241,
................................
................................
dépasse les 2.7Mo
8-)
VDigital a écrit:
Le découpage de la rêquete ou son optimisation étant sur option d'une $conf
car cela ne concerne que les GROS tagueurs (tes tagueurs fous?).
patnoe est un tagueurs à zéro tag!! ;-)
VDigital a écrit:
Nouveau pb (de quoi inquiéter vimages)...
SELECT DISTINCT image_id
FROM phpwebgallery_image_category
WHERE (category_id NOT IN (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,..,12770,12771,12772,12773,12774,12775,12776,12777,12778,12779,12780,))
;
[mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 3
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in E:\www\phpwebgallery\include\functions.inc.php on line 884soit
WHERE (category_id NOT IN (1,2,3,4,5,...,12776,12777,12778,12779,12780,))
near )) c'est la virgule sans doute mais...
Monsieur MySQL, cette requête, plus simple, tourne des milliers de fois par jour.
8-(
Une solution simple et rapide est de passer par la table #cache et par jointure.
Le seule endroit ou ce n'est pas applicable c'est lors de l'alimentation de la table #cache mais il y a plusieurs méthodes pour le faire.
VDigital a écrit:
Plutôt que de faire une jointure... qui sera exponentielle.
Soit:
1 - J'optimiserai la liste
WHERE (image_id between 669 and 694) or (image_id between 89238 and 89473)
or (image_id between 364810 and 367019)
or image_id IN ( 89247, 12667, ..., 342176 )
Je ne suis pas d'accord sur ce cas précis car c'est TOUTE la table image qui est passé en paramètre et par la suite les id images ne sont plus utilisés.
Exponentiel surement pas si les indexes sont correctes (bien au contraire)
Tes autres méthodes fonctionnent bien sur correctement mais dans tes cas où la liste des id est partiel et pas full.
Nouveau pb (de quoi inquiéter vimages)...
SELECT DISTINCT image_id
FROM phpwebgallery_image_category
WHERE (category_id NOT IN (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,..,12770,12771,12772,12773,12774,12775,12776,12777,12778,12779,12780,))
;
[mysql error 1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 3
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in E:\www\phpwebgallery\include\functions.inc.php on line 884
soit
WHERE (category_id NOT IN (1,2,3,4,5,...,12776,12777,12778,12779,12780,))
near )) c'est la virgule sans doute mais...
Monsieur MySQL, cette requête, plus simple, tourne des milliers de fois par jour.
8-(
Pourrais-tu me mettre dans un groupe où je ne verrai que la moitié des catégories...?
Histoire de voir si à moins de 2Mo la requête est traitée normalement et répond instantanément.
8-)