Tag > Show : Affichage des tags enfants ET des items

[svergeylen]

POur le moment, j'affiche que les tags enfants OU les items (quand il n'y a plus d'enfants)

Cela pose un gros soucis quand ce cas :

• plusieurs items ont le tag "A"
• on crée un enfant au tag "A" qui s'appelle tag "B" et on déplace certains items de A dans B mais pas tous
• on n'a plus accès aux items qui sont restés dans A, car l'affichage du tag "A" ne propose plus que le sous tag "B" sans plus jamais afficher d'items du tout... --> perte d'accès aux items de A !

Solution : afficher les enfant du tag A à gauche et les items du tag A à droite.... l'utilisateur voit les items et peut également accéder aux enfants, càd filtrer de plus en plus finement les items présentés à droite... (paginate / limit à mettre évidemment)

[svergeylen]

Problème de performances lorsque affichage des items dans "Bandes dessinées" .. environ 28 secondes...

• impossible d'utiliser paginate sur l'array qui sort du filter_by.... du coup soit on recode le paginate (per_page et offset et une multiplication)

[svergeylen]

Query Item.having-tags à refaire, de façon à pouvoir gagner en performances et pouvoir paginer les items renvoyés (ou équivalent)

[svergeylen]

@dvergeylen coucou. est-ce que tu aurais une bonne idée pour cette query ?

[dvergeylen]

Coucou,

J'espérais regarder aujd mais je n'aurai pas l'occasion. Je fais ça dès que je trouve le temps :small_airplane:

[svergeylen]

Aucun soucis, c'est juste que je souhaitais te laisser la primeur de cette query "centrale" :-)

En gros, il faudrait idéalement :

• pouvoir obtenir les items qui correspondent à plusieurs tags (ex : "voyage"+"routard"+"pays") mais en ignorant les tags non filtrants (tag.filter_items = false)
• pouvoir afficher les x premiers items d'une longue list (ex : tag "bd" , ou tag bonsais), évenutellement en classant par items les plus récemment modifiés
  • et faire plein de tests... :-)

/!\ j'ai changé >= en == dans ta query having_tags (à voir si c'est bon) /!\ il y a des faux positifs car certains tags ont des tags en doublons (model à corriger ?) + je réfléchis à une tache rake pour virer les doublons existants...

[svergeylen]

Update : je ne vois pus d'erreurs de sélection d'items maintenant que les tags en doublons ont été virés (à vérifier sur le long terme).. .par contre, le soucis de performance ce serait bien de le régler pour pouvoir afficher les items des root_tags par ex :-)

[dvergeylen]

Le problème n'est pas dans having_tags, mais dans la vue:

En faisant un test en console:

ar_tags_id = [Tag.find_by(name: "Bandes dessinées").id]
Item.having_tags(ar_tags_id)
# Renvoie 2720 résultats :
# (0.5ms)  SELECT "tags"."id" FROM "tags" WHERE "tags"."id" = 789 AND "tags"."filter_items" = ?  [["filter_items", "t"]]
# (8.2ms)  SELECT COUNT(*) AS count_all, "ownertags"."owner_id" AS ownertags_owner_id FROM "ownertags" WHERE "ownertags"."tag_id" = 789 AND "ownertags"."owner_type" = ? GROUP BY "ownertags"."owner_id"  [["owner_type", "Item"]]
# Item Load (7.6ms)  SELECT "items".* FROM "items" WHERE "items"."id" IN (1, 2, 3, 4,...)

en qq ms, l'essentiel du temps passé n'est donc pas là (bonne nouvelle).

En affichant la vue par contre:

Completed 200 OK in 28275ms (Views: 25621.3ms | ActiveRecord: 2459.0ms)

Il y a donc un problème de n+1 queries dans la vue.

Edit: il y en a plusieurs

Je vais les détailler dans le commit de correction.

Edit 2: résultat obtenu:

Completed 200 OK in 6900ms (Views: 4447.3ms | ActiveRecord: 109.6ms)

[dvergeylen]

Je n'ai pas attaqué la pagination mais à mon avis il faut faire (dans having_tags):

Item.includes(:tags, itemusers: [:user]).where(id: ownertags.keys).limit(per_page).offset((page-1)*per_page).sort_by{ |a| [a.number.to_f, a.name] }

(non testé)

[svergeylen]

ok, merci pour le coup de main, je peux faire la pagination à la main sans le gem paginate (il faudra juste chipoter pour afficher de beauc boutons pour naviger entre les pages, mais l'essentiel, c'est que la page 1 se charge plus rapidement)... (Très bonne nouvelle que ce n'est pas dans la structure de base de données que c'était lent) (et j'ai bcp apprécié les includes(...) dans les query pour éviter de lancer des sous requetes dans une boucle... bonne pratique)

[svergeylen]

Juste commiter dans la branche dev au lieu de master stp, parce que master est d'office l'image de ce qui est en production (j'ai remis master comme "main branch" comme tu m'avais demandé (pour que les message de fix fonctionnent en fait) mais c'est mieux de faire les tests dans dev, si ok pour toi

[dvergeylen]

Aok

Je préférerais faire des pull-request, ce qui permet de tester systématiquement dans un fresh clone et de continuer à commiter dans la même branche s'il fallait faire des changements ultérieurs.

[svergeylen]

Bon, a priori ca semble fonctionner très très bien :

En selection qu'un seul tag : "bonsais", on a plein d'items... on affiche les 24 premiers et à gauche on affiche les tags enfants pour affiner la recherche... On a donc un contenu assez riche : a guauche les tags enfants "vue hiérarchique", à droite les 24 items dernièrement modifiés pour un accès rapide (genre "ha oui, c'est celui là que je viens d'ajouter... " même si on ne se souvient plus dans quel sous-sous-sous-saoul?-tag on l'avait ajouté et tout en bas, les boutons d'actions pour le travail en batch sur plusieurs items :-)

Ya plus qu'à tester ca dans tous les sens non ? :-) (J'ai bcp travaillé le mobile friendly pour etre sur d'avoir un bon colelctor sur smartphone, c'est pas trop mal du tout :-) )

[svergeylen]

1f7728335bd6af4f22aeb7086e0eaf678c7c0887