sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-users] RE : [sdx-users] RE : Caching (était : Re: [sdx- users] pb a


From: Martin Sévigny
Subject: [sdx-users] RE : [sdx-users] RE : Caching (était : Re: [sdx- users] pb avec la requete id)
Date: Thu, 7 Mar 2002 12:55:28 +0100

Bonjour,

> Sans aller dans auatnt de complexité, ne peut-on envisager 
> d'ajouter un 
> paramètre au servlet qui contiendrait l'ID de session et donc 
> "d'émuler" 
>   la transmission telle quelle se fait via une request HTTP 
> en bonne et 
> due forme ? Je vais regarder le code plus en détail et voir les 
> implications de cette approche...

Ce n'est malheureuseument pas si simple. Je ne vois pas dans l'API des
sessions une méthode pour récupérer une session via son identifiant. On
les retrouve normalement par l'objet HttpServletRequest, donc par la
requête. Il faudrait donc que SDX stocke toutes les sessions en cours
(dans l'environnement SDX) pour qu'on puisse les atteindre depuis une
servlet SDX.

N'oubliez pas que votre problème est simple : vous voulez faire partager
des informations à deux sessions différentes. Le partage de la session
elle-même n'est peut-être pas la seule solution.

> Malheureuseument, je n'ai pas la luceneQuery dedans.

C'est vrai.

> - soit je patche la taglib pour inclure la luceneQuery sans 
> sdx:navigation

Très simple. Ne pas oublier de patcher la doc!

> Quand bien même, cette solution me paraît sans issue car je n'ai pas 
> d'API capable de me balancer telle quelle une luceneQuery à laquelle 
> j'aurais concaténé mon critère de recherche supplémentaire (option 
> apparemment choisie par Rui). En effet, le mise en minuscules 
> me flingue 
> cette approche :-)

La mise en minuscules de quoi? Si tu as un requête Lucene initiale
nommée r1, je pense que faire +(r1) +r2 où r2 est ton nouveau critère te
fera un ET logique entre les deux, non?

Ah, je vois, tu ne pourras pas l'envoyer en requête SDX de type
simple... Tu as parfaitement raison.

> C'est pour cela qu'il faudra probablement un jour envisager un autre 
> stockage qu'un arbre DOM particulièrement réputé pour sa consommation 
> mémoire... Mais bon, on aura le temps d'en reparler...

Oui, mais en fait je ne crois pas qu'il y a un DOM de stocké. C'est une
objet SDXResults qui est stocké, les DOM de page ne sont pas
précalculés, évidemment. Et je ne crois pas qu'ils sont conservés après
utilisation, mais c'est à vérifier. Je ne crois pas qu'il y ait de DOM
stockés dans SDX.

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]