Re: [sdx-users] RE : Caching (était : Re: [sdx-users] pb avec la requete id)

[Pierrick Brihaye]

Martin Sévigny wrote:

> Non, pas du tout, en cookie il a l'identifiant de session, c'est tout,
> la session est sur le serveur. C'est le moteur de servlets qui la gère.


Oups ! Je pose mes questions *avant* d'avoir rejeté un oeil sur le code, 
je sais que ce n'est pas bien :-)

Cela veut dire que c'est bien le *serveur* qui :
- stocke *en mémoire* les infos de session (les baseQuery dans mon cas) ?
- détruit les requêtes dès lors qu'il en a plus de 5 (nombre par défaut) ?


> Le problème est que les servlets de recherche n'exploitent pas les
> informations de session, contrairement à l'API XSP.


Euh, là, je pers les pédales : mon servlet tourne, en XSP, ça tourne 
aussi. C'est à la transformation (XSL) que ça ne tourne pas car, l'appel 
à document() ne semble transmettre aucune info de session, non ?

> A ajouter. 


Tu vois ça comment ?

Note : je vais expliquer ma demande fonctionnelle.

1) SDX me permet de retrouver un jeu de résultats {A} à partir d'une 
requête X.

2) J'affiche un des membres de {A}.

3) Celui-ci contient un lien (hypertexte) vers un document B.

4) Voici la logique que je veux mettre en oeuvre à partir de là :

Si B est membre de {A}, je continue la navigation dans la requête : 
passer au résulttat N (indice de B dans {A})
Si B n'est pas membre de {A}, je préviens que l'utilisateur est en train 
de sortir de la requête.

D'où la baseQuery (la requête) et une requête secondaire sur 
l'identifiant de B...

Il est clair que cette approche n'est pas bonne car, dès le 5ème lien 
(et encore, à condition que je sois le seul utilisateur ?), ma baseQuery 
n'est plus valide. Je vais donc faire autrement en concaténant la 
luceneQuery de la requête de base avec une reuqête sur l'ID des 
documents liés. MAis bon, elle a au moins eu le mérite de mettre le 
problème en évidence :-)


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