Ticket #1034 (closed enhancement: wontfix)
Permettre la gestion de cache dans dblayer::select
Reported by: | bruno | Owned by: | xave |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | module:clearbricks | Version: | 2.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
Il serait intéressant de permettre d'intercepter dblayer::select pour le mettre au profit par exemple d'un gestionnaire de cache.
L'ajout d'un paramètre optionnel de type "caching policy" permettrait en plus à l'appelant d'avoir un meilleur contrôle sur la mise en cache ou non des résultats.
Attachments
Change History
comment:1 Changed 14 years ago by bruno
Ci-joint une proposition d'évolution :
- ajout d'une interface i_dbCacheEngine
- renommage de dblayer::select en dblayer::dbselect
- ajout de dblayer::select qui appelle cache->select ou dblayer::dbselect si cache est null.
dblayer::select prend un paramètre optionnel cache_policy, qui permet de forcer la mise en cache, de forcer la non-mise en cache ou de laisser le moteur de cache gérer tout seul.
Le moteur de cache peut aussi être notifié d'une requête pouvant faire une modification en base
comment:4 follow-up: ↓ 5 Changed 13 years ago by Tomtom33
Le trigger pour mettre à jour le cache sur fait:
- lorsqu'il y a un execute() qui passe?
- sur l'ensemble du cache ou c'est sélectif? Je veux dire, si il n'y a eu qu'une modification sur les commentaires, le cache pour les billets est lui aussi réinitialisé?
comment:5 in reply to: ↑ 4 Changed 13 years ago by bruno
Replying to Tomtom33:
Le trigger pour mettre à jour le cache sur fait:
- lorsqu'il y a un execute() qui passe?
- sur l'ensemble du cache ou c'est sélectif? Je veux dire, si il n'y a eu qu'une modification sur les commentaires, le cache pour les billets est lui aussi réinitialisé?
Le patch permet juste d'intégrer un cache mais n'en fournit pas, libre au cache de choisir ce qu'il fait ensuite. Le cache est notifié d'un execute avec la requête SQL associée, c'est à lui de déterminer ce qu'il considère ensuite comme "dirty" ou pas.
Voir http://www.morefnu.org/public/archives/dotclear2/plugins/dbcache/plugin-dbcache-0.1.zip pour un exemple de cache db
comment:6 Changed 13 years ago by bruno
Le plugin date un peu, c'est juste un PoC. Je viens de me rendre compte que la partie gestion des "dirty" n'est pas faite. Mais rien n'empêche de parser la requête SQL pour déterminer quelles sont les tables impactées, et vider le cache en conséquence...
comment:7 follow-up: ↓ 10 Changed 13 years ago by bruno
- Status changed from new to closed
- Resolution set to wontfix
Finalement, trop redondant avec une bonne optimisation en base...
comment:8 Changed 10 years ago by bruno
- Status changed from closed to reopened
- Resolution wontfix deleted
Oh là-bas, un signe à trois-têtes ! [:sifflote]
comment:10 in reply to: ↑ 7 Changed 8 years ago by franck
- Status changed from reopened to closed
- Resolution set to wontfix
Replying to bruno:
Finalement, trop redondant avec une bonne optimisation en base...
En conséquence, je clos sans donner suite :-)