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?

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

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.

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).