Re: [sdx-users] cache cookie

[Pierrick Brihaye]

Salut,

Malo Pichot a écrit:

> Plus encore, on travaille souvent par tatonnement pour isoler de 
> tel corpus. C'est bien agréable ici d'isoler les étapes de 
> construction de la requête. Une dernière chose, lorsque l'on 
> souhaite étudier les variantes d'un même phénomène, c'est bien 
> agréable de pouvoir isoler la "racine" d'une requête.

C'était le sens de mon intervention.

> Tout cela me fait dire que cette fonctionnalité est bien 
> intéressante. Elle mérite que l'on dégage le temps nécessaire 
> pour produire un travail correcte.
>
> Enfin, à la réponse "que cacher", je répondrais : "les deux, mon 
> capitaine !". Il faut pouvoir "cacher" et le jeu de résultats et 
> la requête. Je vois un intérêt certain à "cacher" la requête (je 
> me suis expliqué plus haut). J'en vois un autre à "cacher" le 
> jeu de résultats qui représente un état X d'un corpus Y à la 
> date Z. Et ça, c'est bien intéressant lorsque l'on met plusieurs 
> mois (plusieurs années) à construire le corpus que l'on souhaite 
> étudier.

<citation copyright="pb">On est d'accord</citation>

A vrai dire, je me demande si le cache des résultats au delà d'une 
certaines limite (très basse d'ailleurs) n'est pas un gouffre à 
performances (v. message d'Emmanuel Begué) dont le serveur assume la 
plus grande part. En ce sens, 5 jeux de résultats me paraissent 
suffisants... si, à côté, on implémente un cache de *représentations 
textuelles de requêtes*.

Certes, ça oblige à recréer des objets query à chaque fois, ce qui est 
dispendieux. D'un autre côté, ces objets génèrent des Bitsets Lucene qui 
sont, eux, très raisonnables en espace mémoire (1 bit = 1 document) ; 
l'un devrait donc compenser l'autre.

C'est bel et bien la construction d'un objet de résultats qui prend de 
la ressource (à cause des champs brief). Il faudrait (yaka ;-) la 
différer au maximum.

Mais, là où le bâte blesse, c'est quand on veut trier car, pour trier, 
il faut bien disposer des clés de tri (ces fameux champs brief... ou 
d'autres : c'est techniquement possible)... et donc construire *tous* 
les résultats.

Note : on avait évoqué de ne permettre le tri que lorsque le nombre de 
documents est inférieur à un certain seuil. Ceci évite par exemple à un 
newbie de faire des requêtes triées sur tout le coprus avant d'affiner 
ses choix. Un peu totalitaire mais ça évite au serveur de se consacrer 
en quasi-totalité aux newbies :-)

Donc... je ne vois pas très bien comment faire... sauf à imaginer un 
stockage provisoire sur une architecture capable de faire rapidement des 
tris et, surtout, de ne renvoyer que la page désirée (ResultsPage vs. 
Results). Et pour avoir ça... il faut coder (beaucoup).

On pourrait aussi imaginer, si les tris sont déterministes de générer 
des bitsets ordonnés suivant ces dites clés de tri déterministes. Un 
truc du genre :

<sdx:sortConfiguration id="aaa">
  <sdx:sortKey field="field1"/>
  <sdx:sortKey field="field2"/>
</sdx:sortConfiguration>

... dans le fichier de config. Et un truc du genre :

<sdx:execute*Query ...>
  <sdx:sort id="aaa"/>
</sdx:execute*Query>

Mais, là aussi, il faut coder.

Il y a un autre problème :

Dans la gestion de la représentation textuelle des requêtes : un texte, 
s'il repassait par le QueryParser ne renverrait pas le même résultat !

1) parce que le mécanisme de remplacement du champ par défaut est... 
bizarre.
2) parce que la très intéressante possibilité de faire une FieldQuery 
non analysée par utilisation des caractères "|" ne renvoie pas ces 
caractères :-( Et encore, je ne parle que du QueryParser par défaut.

J'ai mis du temps à me convertir à la SimpleQuery, mais je mets 
désormais beaucoup d'espoirs en elle :-)

C'est ma grosse priorité en ce moment et je compte bien avoir résolu ça 
pour la semaine prochaine.

Voilà.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden