RE : [sdx-users] Travaux de développement sur SDX

[Rasik Pandey]

Salut,

> > - au niveau de l'indexation proprement dite, dans le cas de
> l'indexation
> > d'un répertoire, il serait intéressant que SDX puisse de lui-
> même parcourir
> > une arborescence de répertoires (c'est à dire que selon un
> paramètre qui
> > pourrait être subdir="true", il indexe le contenu des
> répertoires sous
> > le répertoire fourni) plutôt qu'on doive lui soumettre chaque
> > répertoire l'un après l'autre (c'est peut-être déjà possible
> d'ailleurs?)
> 
> Pour autant que je m'en souvienne, la lecture des répertoires
> est
> récursive. Mais bon, tout à fait entre nous, je n'ai jamais
> bien compris
> le code de récursivité de la logicsheet :-)

On a vu avec Malo qu'on pourrait bien améliorer la façon de "scanner" le 
répertoire comme dans le "DirectoryScanner" de ANT.

> > - toujours à propos de l'indexation, il serait également très
> intéressant
> > qu'on puisse calculer dans la xsl d'indexation un paramètre
> qui serait
> > comparé à la valeur d'un champ pour ce document, si un
> document de même
> > identifiant est déjà présent dans l'index; le nouveau
> document ne serait
> > indexé que si cette valeur est différente/supérieure à la
> valeur indexée
> > (=> première utilité: n'indexer que les documents dont la
> date de mise
> > à jour est supérieure à la date d'indexation, cad qui ont été
> modifiés
> > depuis la précédente indexation -- comparaison avec
> sdxmoddate; mais on
> > peut en imaginer d'autres)
>
> En gros, tu voudrais une indexation conditionnelle ? Si c'est
> le cas : +1.
>  >  -- c'est peut-être aussi déjà possible?
> 
> A priori non : si tu as décidé d'indexer, tu dois mener le
> processus à
> terme car la dynamique actuelle est d'effacer l'indexation
> avant de
> sauvegarder la nouvelle si bien qu'un retour en arrière est...
> difficile.

IMHO, de comparer des champs Lucene d'un document sera du gaspillage de 
ressources car on sera obligé de passer par une transformation, une recherche 
pour retrouve le document, etc. D'ailleurs de comparer de champs au niveau de 
Lucene ne sera pas performante car on voit avec les derniers messages sur la 
liste lucene-dev que tous les champs d'un document sont forcement retournés 
quand on accède un document. Je crois que Myriam a développe un "daemon" 
d'indexation de scanner un répertoire de documents pour savoir quels documents 
étaient changés. Je vois cette service comme une couche au-dessus d'une base de 
documents. Peut-être il faut avancer cette idée un peu plus mais crois qu'on a 
déjà la base avec le ModifiableSource de Cocoon.

> > - au niveau Lucene, on lit dans la liste des changements
> récents que
> > depuis la version 1.4RC1 (point 5):
> >     Added support for hit sorting. Results may now be sorted
> by
> >     any indexed field. (Tim Jones via Cutting)
> > (cf.
> > http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-
> lucene/CHANGES.txt?rev=
> > 1.85)
> >
> > "any" est peut-être beaucoup dire
> 
> Très juste. Cependant, utiliser cette fonctionnalité serait
> effectivement *très* intéressant.

Il y a dix jours j'ai bien recherché le nouveau tri de Lucene. A mon avis, les 
fonctionnalités qui manquent au niveau Lucene sont le tri de valeurs String 
respectant une langue (Locale) et le *rétri* des résultats (l'objet Hits de 
Lucene). 

Du point de vue de développement, on n'a pas beaucoup à faire?


Rasik