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

[Pierrick Brihaye]

Bonjour,

Je prends le débat en route...

Martin disait :

>Jusqu'à maintenant, c'est la première
>personne (à ma connaissance) qui évoque clairement ce besoin

Je me souviens avoir évoqué le problème (chez [sdx-developpers]) sous un
angle plus technique à savoir comment générer un objet SDXResults à partir
d'une requête "statique". L'objectif était bien là : proposer des cartes de
site ou des "sélections du chef" :-)

> 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... ;-)

Pour moi, ça ne l'est pas : hélas....

Ca sous-entend *en plus* que :

le corpus *d'indexation* n'a pas varié
la façon de formuler les résultats n'a pas changé non plus.

Or, c'est précisément là où je coince (un peu). Les résultats sont à l'heure
actuelle générés dynamiquement par SDX (champs brief) et, de plus, ils sont
forcément dépendants du jeu d'index utilisé (ce qui est une contrainte
inutile IMHO). Idéalement, j'aurais aimé pouvoir séparer indexation et
résultats et passer ces deux données (que j'avais appelées "vues") en
paramètres de queries. Dans ces conditions, on peut avoir des identifiants
uniques qui pourraient effectivement servir de clés de cache.

Ensuite, se pose le problème de savoir à qui on confie la gestion du cache.
A SDX ? Il faudra coder... A Cocoon ? On devra donc faire aveuglément
confiance à ce logiciel...

Personnellement, je n'ai pas la réponse :-)

> 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?

A moi non plus :-)

> 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)?

Les deux :-) Mais ça devrait être facile à gérer en utilisant les API de
cache de Cocoon qui sont assez puissantes sur le papier. En gros, on
pourrait passer au XSPGenerator de quoi indiquer si on doit utiliser le
cache ou pas. Normalement, le simple fait de modifier la XSP l'invalide ; il
faudrait aller plus loin avec les paramètres (ça doit être facile) et avec
les locations, ou plutôt, avec un timestamp sur les dernières mises à jour
des différentes locations utililsées.

> (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)

Oui.

> Partir des urls est peut-être brutal,

C'est à priori fiable si une MAJ de location est correctement notifiée.

> et surtout c'est peut-être
> le signe que le cache pourrait être pris en charge par le serveur
> web au lieu de SDX;

Oui.

> à l'intérieur de SDX il serait peut-être plus
> fin de comparer les éléments sdx:query ...?

Mmmh : j'ai bien peur que ça nous amène à un affreux LuceQueryComparator
:-)))

A+

p.b.