Produits Entr'ouvert » BiJoe

le lien de suppression s'affiche sur la même ligne en restant dans les clous de gadjo

Tu peux regarder l'écran de configuration d'un agenda d'événements dans chrono, ça fait exactement ça.

Valentin Deniaud a écrit :

J'ai fait les deux.
Le patch 2 n'est pas suffisant, je ne sais pas comment faire pour que le lien de suppression s'affiche sur la même ligne en restant dans les clous de gadjo. J'ai essayé de mettre les mêmes classes que les listes à boutons dans wcs, mais une partie du style que les fait marcher est dans admin.css, donc ça n'a pas fonctionné.

Pourquoi une staticmethod au lieu de juste faire visualization.cube_exists dans le template ? Ça m'a l'air inutilement tordu (et puis ça pourrait s'appeler simplement .exists ou .valid ou .ok).

C'est toujours assez moche, je préfèrerai vraiment un {% if visualization.exists %} pour ce qui est de l'esprit du code si il peut être amélioré tant mieux (il y a effectivement beaucoup de chose dans utils.py si ça peut être progressivement remigrer sur le modèle ce n'est pas plus mal).

Pour tout le reste c'est bon.

Oui mais il nous faut un accès à request, je ne connais pas de méthode pour m'en sortir avec un appel depuis le template (à part le stockage global de l'objet via un middleware mais a-t-on envie d'en arriver là). Sinon un template tag ?

Valentin Deniaud a écrit :

Oui mais il nous faut un accès à request, je ne connais pas de méthode pour m'en sortir avec un appel depuis le template (à part le stockage global de l'objet via un middleware mais a-t-on envie d'en arriver là). Sinon un template tag ?

Le tenant est disponible globalement sur django.db.connection.tenant on peut passer par là plutôt que par request dans get_warehouse(), le cache peut-être fait globalement avec une durée courte (genre 30 secondes) par rapport au chemin, ce n'est pas un truc qui bouge.

Mince j'avais pas vu mais le build jenkins est redevenu assez long (1h30 au lieu de 20min)... Rien à voir avec les 10h que ça prend sans cache, mais quand même bien problématique.

1. Pour voir si les données existent, on doit aller les demander aux objets Warehouse
2. La fonction get_warehouses fait des lectures sur le disque, c'est long, mais ça n'était pas grave car il y avait un seul appel au moment d'aller voir une visu
3. Maintenant à l'affichage de la page d'accueil, on a autant d'appel à get_warehouses que de visualisations, c'est lent
4. test_schema2.py lance 400 fois un test et affiche à chaque fois la page d'accueil, donc 400^2 appels à get_warehouses, c'est très lent
5. Il faut donc brancher un système de cache pour cette fonction
6. Première idée : cache comme un simple attribut sur la requête, ce qui réduit le nombre de vrais appels à 400 --> les tests retrouvent une durée d'exécution normal
7. Sauf qu'on supprime l'objet request dans get_warehouses pour des raisons plus haut, donc recours au cache django, ce qui réduit le nombre de vrais appels à 2 (les deux schémas différents utilisés dans les tests).
   Et je n'avais pas pensé à vérifier mais en fait c'est un peu lent (0.07s à 0.03s sans cache, de 0.01 à 0.001 avec).

Je vais continuer d'investiguer, et finir par trouver une solution.

Passe sur un autre ticket.