Bonjour à tous,

Pour la correction un peu complexe de [Bugtracker] ticket 937, j'ai dû ajouter des requêtes SQL et malheureusement ce sont des requêtes SQL très coûteuses car elles utilisent un "order by rand()" qui peut faire mal sur des grosses galeries. Pour contrer cette augmentation de charge SQL, j'ai implémenté un système qui met en cache la miniature à afficher pour tel album pour tel utilisateur. Comme je trouvais le système très efficace, je l'ai généralisé hors du cas particulier "cette miniature n'est pas autorisée à tel utilisateur".

Concrêtement, on y gagne en performances SQL (et de manière vraiment significative car on vire toutes les requêtes qui consomment beaucoup) mais on y perd en "aléatoirité". Je vais donner un exemple pour qu'on me comprenne.

Imaginons l'arborescence suivante:

* évènements
-- * anniversaire Paul
-- * mariage Benjamin
---- * église
---- * soirée
* nature
-- * flore
-- * faune
---- * felins
---- * oiseaux

En 2.1: la miniature représentant "nature" est choisie parmi les miniatures représentant {flore, felins, oiseaux}, le résultat peut changer à chaque rafraichissement de la page

En 2.2 : au premier passage du visiteur, la miniature représentant "nature" est choisie parmi les miniatures représentant {flore, felins, oiseaux}, par exemple "oiseaux", cette miniature est mise en cache. Dès le second passage, on réutilise la miniature en cache, donc ce sera toujours "oiseaux".

Le cache est réinitialisé par certaines actions d'administration comme l'ajout de photo ou des modifications sur les permissions donc le cache a une durée de vie limitée, mais on peut considérer que pour une visite donnée, chaque album aura une seule et unique miniature représentante.

rvelices a tout de suite remarqué ce changement et s'est demandé si je n'avais pas introduit un bug. J'ai expliqué que c'était une conséquence de l'amélioration de performances.

Est-ce que, à l'utilisation de la 2.2.0RC1, vous avez constaté ce changement et pose-t-il un problème à votre avis ?