coolsocks a écrit:
J'ai mis en palce ce matin au réveil
C'EST SUPER
C'est exactement ce que je cherchais
Un GRAND merci à toi Rub
C'est vrai que cela marche à priori bien chez toi...
Bravo rub.
Hors ligne
VDigital a écrit:
Par contre, le code - très joli au demeurant - est loin de la solution finale, heureusement.
heureusement? Pourquoi?
Car pas de cache et limité aux menus?
En me répétant, ce qui compte dans ce bout de code, c'est l'algo de calcul des date_last.
Le calcul en php pour les branch non_expand se fera par exemple comme avant en sql.
Je vais travailler la suite pour la version Alligator, donc les modifications seront disponibles sur gna mais difficile et très risqué à appliquer sur une branche 1.6.
VDigital a écrit:
Bien joué, rub, une bonne leçon de coding avancé (mais quasiment non maintenable malheureusement).
non maintenable malheureusement? Pourquoi?
Sûrement dans le contexte d'un bout de code dans un topic du forum.
Egalement si c'était un MOD.
VDigital a écrit:
PS: Ceux qui seraient tenté avec un grosse galerie (+ de 200 catégories), vous pouvez faire le test, et éventuellement prévoir le retour arrière.
Par contre, nous serions certainement tous très curieux d'avoir un retour sur le temps de réponse.
J'avais testé avec 450 catégories en local, donc ça devrait aller mais il est de rigueur de toujours être prudent lors de mise du code comme ca dans un topic (les bugs et les effets de bord sont la pour nous le rappeler).
En tout cas, faites remonter les problèmes car l'algo de calcul va être repris dans une branche officielle.
Hors ligne
coolsocks a écrit:
J'ai mis en palce ce matin au réveil
C'EST SUPER
C'est exactement ce que je cherchais
Un GRAND merci à toi Rub
VDigital a écrit:
Bravo rub.
Content que ça plaise.
Et si ça peut être mis en place au réveil, c'est que c'est simple à installer! lol!
Hors ligne
Oui, oui, nous sommes d'accord.
Et dans un premier temps, tu t'es amusé à le faire, et c'est surprenant d'efficacité même si ce qui existera, le sera encore bien plus.
PS: "(les bugs et les effets de bord sont la pour nous le rappeler)", oui, je vois bien de quoi tu parles. 8-)
Hors ligne
rub a écrit:
Car que va-t-on avoir dans #user_cache.cat_date_last?
Un truc comme ca "cat_id1,date1 | cat_id2,date2 | ... | cat_id3,date3"?
Donc, il faut faire une explode "|" de cette chaine texte puis pour chaque élement (c'est ici qu'on parcoure ;-)) un explode ","?
Si il y a plus simple, je suis preneur. (Je n'ai pas trop pratiqué des preg_*, etc.)
Surtout ne pas faire comme cela. Il faut faire un vrai tableau en PHP:
// 1. create a true PHP array $user_cat_date_last = array( 13 => '2005-05-01', 14 => '2006-03-21', 15 => '2007-01-01', ); // 2. serialize it $user_cat_date_last_string = serialize($user_cat_date_last); // 3. later, unserialize it $user_cat_date_last = unserialize($user_cat_date_last_string);
Hors ligne
Bon bahhh voila
moi aussi j ai fais le test ce matin en live et ...
C EST NICKEL
maintenant je patiente pour la version finale mais les perfs sont bon et le resultat parfait
a+ et bon courage
Hors ligne
En ce qui me concerne ca fonctionne parfaitement et pas de ralentissements.
Hors ligne
z0rglub a écrit:
rub a écrit:
Car que va-t-on avoir dans #user_cache.cat_date_last?
Un truc comme ca "cat_id1,date1 | cat_id2,date2 | ... | cat_id3,date3"?
Donc, il faut faire une explode "|" de cette chaine texte puis pour chaque élement (c'est ici qu'on parcoure ;-)) un explode ","?
Si il y a plus simple, je suis preneur. (Je n'ai pas trop pratiqué des preg_*, etc.)Surtout ne pas faire comme cela. Il faut faire un vrai tableau en PHP:
Je me disais bien que je passais à côté de quelque chose, je ne connaissais pas encore ces fonctions.
Hors ligne
Voila mon 1er commit sur l'intégration de la nouvelle notification de mise à jour.
Plus un 2eme par oubli de fichier
Finalement, je suis parti sur un développement avec une nouvelle table pour y ajouter outre la date de modification la plus grande, les informations suivantes:
1 oui/non, si la date est une date provenant de ces fils (la, j'avoue ca aurait pu être sans table cache)
2 le nombre total d'images de la catégorie et de ses sous-catégories
3 le nombre total de sous-catégories
Utilisation de ses informations:
1 pour afficher une icône différente
2&3 pour afficher plus d'informations dans le menu, les miniatures des catégories et les infos bulles du menu.
Quelques copies d'écrans apporteront des précisions:
Je n'ai pas mis de $conf pour le choix de l'affichage (il faudrait ???) et bien entendu si ça ne plait pas, je refais (à regret) un rollback.
Dernier point, quand on clique sur les catégories récentes, l'icône n'est pas présente (alors qu'elle l'est pour les images récentes). Pour être uniformes entre les images et les catégories, je supprimerais bien ce comportement qui n'apporte pas grand chose à mon gout.
Dernière modification par rub (2006-12-02 00:46:59)
Hors ligne
Je n'ai pas été compris, visiblement. 8-/
Ce n'est pas grave pour moi...
Cela reste une erreur de conception qui a des conséquences relativement faibles coté performances.
8-)
Hors ligne
VDigital a écrit:
Je n'ai pas été compris, visiblement. 8-/
Ce n'est pas grave pour moi...
Cela reste une erreur de conception qui a des conséquences relativement faibles coté performances.
8-)
La, c'est moi qui n'ai pas tout compris?
Qu'est-ce que je n'ai pas compris?
Quelle est l'erreur de conception?
C'est l'utilisation de d'une nouvelle table contre celle d'un champ des valeurs sérialisées?
Franchement, si c'est ca les performances sont identiques.
Entre la mise en place d'un tableau et un where avec des not in contre une requête avec jointure, je penses que les résultats sont comparables aussi bien en perf qu'en mémoire (quoi que).
Hors ligne
Je suis surpris de la présence du user_id dans la table et que cette table est unique, c'est tout.
Si tu crées un table incluant le user_id, cela signifie pour moi que la last_date est recalculée pour chaque catégorie et pour chaque user.
Obligatoirement.
Une grande galerie comme celle de v_images qui contient 1900 catégories et 360 utilisateurs, même en supposant que seuls 36 utilisateurs sont actifs et que ceux-ci ne voient guère plus de la moitié des catégories, tu calcules tout de même 36*950 last_dates.
Je te proposais dans mes explications de ne pas retenir le user_id pour n'avoir n'avoir que 1900 lignes ou moins.
Les catégories parentes ou vides n'ayant pas de ligne dans la table ou une last_date à NULL.
Je crois que c'est plus léger et que cela fonctionnait quand même.
Cela impliquait au moins une petite modif à l'issue de la synchro (que je ne vois pas).
Ton bel algo s'appuyant sur cette table pour calculer les dates de catégories parentes en fonction des droits du user.
Je n'ai pas cherché encore à comprendre ce que tu as fait (il faudra que je le fasse pour pouvoir comparer).
Cependant, je reste persuadé que je me suis bien mal exprimé pour n'avoir pas su faire comprendre que les dates devaient être calculées en deux temps.
Un premier pour les catégories quelques soient les droits.
Puis un second temps, à partir du résultat précédent, en fonction des droits de l'utilisateur en ligne.
Mais cela n'a aucune importance au final, puisque cela marche.
Quand j'aurai un moment, je reviendrai expliquer le processus (qui ne remet pas en cause l'algo).
8-)
Hors ligne
VDigital a écrit:
Je suis surpris de la présence du user_id dans la table et que cette table est unique, c'est tout.
Mais ca ne veut pas dire que c'est calculer pour tous à chaque fois d'un coup.
C'est calculé, si nécessaire, en même temps que le forbidden_categories pour un utilisateur en particulier.
Unicité de la table? c'est à dire?
VDigital a écrit:
Si tu crées un table incluant le user_id, cela signifie pour moi que la last_date est recalculée pour chaque catégorie et pour chaque user.
Obligatoirement.
Oui mais pas en même temps, seulement selon les besoins.
VDigital a écrit:
Une grande galerie comme celle de v_images qui contient 1900 catégories et 360 utilisateurs, même en supposant que seuls 36 utilisateurs sont actifs et que ceux-ci ne voient guère plus de la moitié des catégories, tu calcules tout de même 36*950 last_dates.
si on faisait tout en même temps comme dans les versions précédentes à ce qu'il parait (cf. Pierrick).
Mais la, ce n'est pas le cas.
J'ai fait mes tests avec 439 catégories (le nombre d'utilisateurs n'influe pas sur les performances) est les temps de réponses sont correctes.
VDigital a écrit:
Je te proposais dans mes explications de ne pas retenir le user_id pour n'avoir n'avoir que 1900 lignes ou moins.
Les catégories parentes ou vides n'ayant pas de ligne dans la table ou une last_date à NULL.
Je crois que c'est plus léger et que cela fonctionnait quand même.
Cela impliquait au moins une petite modif à l'issue de la synchro (que je ne vois pas).
Ton bel algo s'appuyant sur cette table pour calculer les dates de catégories parentes en fonction des droits du user.
On n'est pas parti sur le même algo, ca c'est sur... ;-)
Explique un peu ton algo et ta modification de la synchro?
VDigital a écrit:
Je n'ai pas cherché encore à comprendre ce que tu as fait (il faudra que je le fasse pour pouvoir comparer).
C'est la que la bat blesse car...
VDigital a écrit:
Cependant, je reste persuadé que je me suis bien mal exprimé pour n'avoir pas su faire comprendre que les dates devaient être calculées en deux temps.
Un premier pour les catégories quelques soient les droits.
Puis un second temps, à partir du résultat précédent, en fonction des droits de l'utilisateur en ligne.
... car c'est bien ce qui a été fait....
Il y a bien 2 calculs, les mêmes que ceux tu te décris.
VDigital a écrit:
Mais cela n'a aucune importance au final, puisque cela marche.
Quand j'aurai un moment, je reviendrai expliquer le processus (qui ne remet pas en cause l'algo).
Si, c'est important d'en discuter car au final, on a bien la même idée en tête, 2 calculs distincts.
C'est simplement la mise en place qui est différente, d'ou l'incompréhension.
PS: Bientôt, les modifs dans ce topic pour avoir la nouvelle icône dans les version 1.6.x
Hors ligne
aie aie aie
je suis dans la caille
j ai voulu faire le malin et maintenant ca marche plus et en plus j ai fais ca en direct !!!!
donc je suis allé repiqué les modif de rub ... et maintenant l affichage des categories dans la colonne de gauche marche plus :-[
apparament en fait c etait pas tout a fait les meme fichiers non ???
bon bahhh si quelqu un peu jeter un coup d oeil merci d avance
Hors ligne
Nicco a écrit:
j ai voulu faire le malin et maintenant ca marche plus et en plus j ai fais ca en direct !!!!
donc je suis allé repiqué les modif de rub ... et maintenant l affichage des categories dans la colonne de gauche marche plus :-[
T'as pas peur!
Surtout que c'est des dev fait en BSF.
Tu as fait comme modifications? L'application des différences?
Va dans administration, simplement pour que les need_udpate soient pris en compte, ca peut-être résoudre ton soucis.
Dernière modification par rub (2006-12-02 13:57:30)
Hors ligne