RE: RE : [sdx-users] Mécanisme de cache?

[Emmanuel Bégué]

> -----Message d'origine-----
> De : address@hidden
> [mailto:address@hidden
> De la part de Martin Sevigny
> Objet : RE : [sdx-users] Mécanisme de cache?
>
> > D'une manière générale d'ailleurs, il serait intéressant de
> > cacher les résultats d'une recherche tant que le corpus n'a
> > pas évolué (entre deux indexations), puisqu'il est impossible
> > qu'à corpus identique les résultats soient différents?
>
> Ce que je peux dire, c'est que l'architecture de SDX ne pose pas de
> problème particulier pour implanter un mécanisme de cache des requêtes,
> du moins il ne m'en vient pas à l'esprit. Par contre, si on voulait
> implanter ce type de fonctionnalités, il faudrait répondre à cette
> question fondamentale : comme savoir que deux requêtes de recherche sont
> identiques?
>
> Cette question est importante et la réponse pas si évidente, et je ne
> suis pas certain qu'il y a même une réponse universelle. Pour lancer le
> débat (et éventuellement susciter l'intérêt des développeurs), vous
> pouvez déjà nous donner votre point de vue ;-)

Pour moi deux requêtes sont identiques si l'url qui les déclenche est
identique? mais je suppose que si vous posez la question c'est que ce
n'est pas si simple... ;-)

Pourtant, il semble que:
- à corpus identique
- à xsp inchangées
deux url identiques produisent exactement la même requête, et donc
le même objet résultat?

Il peut arriver que des urls différentes produisent le même objet
résultat (en particulier, parce que l'ordre des paramètres est
indifférent), mais ce cas ne semble pas très important: on n'aura
pas, alors, utilisé le cache alors qu'on aurait pu. Si le cache
"attrape" correctement 90% des requêtes identiques, par exemple,
et en laisse passer 10% qu'il aurait pu traiter mais pour lesquelles
une recherche est effectuée à nouveau, cela ne semble pas très
grave?

L'autre cas serait beaucoup plus gênant: qu'une requête soit
considérée comme cachée alors qu'elle ne l'est pas. En partant
des urls, ce cas ne semble pouvoir se produire que si les xsp
sous-jacentes ont été modifiées (ou le corpus)? Pour éviter
cela, peut on dire que:
- le cache est organisé par xsp
- toute modification d'une xsp entraîne la destruction du cache
associé
- toute modification du corpus entraîne la destruction de
tous les caches

(un décaching plus fin (du genre: si une base est mise à jour
dans une application multi-base, je ne détruits que le cache
associé aux xsp qui utilisent cette base, etc.) est potentiellement
infiniment complexe pour un gain réel faible)


Partir des urls est peut-être brutal, et surtout c'est peut-être
le signe que le cache pourrait être pris en charge par le serveur
web au lieu de SDX; à l'intérieur de SDX il serait peut-être plus
fin de comparer les éléments sdx:query ...?

Cdt,
EB