Re: RE : [sdx-developers] Le highlighter de la mort

[Pierrick Brihaye]

Re,

Rasik Pandey a écrit:

>  >else {
>  >   char[] chars = tokenText.toCharArray();
>  >   if (chars != null)
>  >     this.xmlConsumer.characters(chars, 0, chars.length);
>  >}
>  >
>  >Va donc me renvoyer *chaque* token qui n'est pas dans la "liste de 
>  >termes" : this.terms (qui pourrait être renommée 
>  >this.wantedHighlights 
>  >?). 
>
> Mais si tu le corrige du coté de la requête (QueryParser) toute tes
> termes iraient apparaître dans cette liste.

Euh... je ne comprends pas bien la réponse.

Mon problème est là :

while ((token = stream.next()) != null)

Ce qui va me renvoyer des tokens dont certains sont à la *même* 
position. Ce qui veut dire qu'à chaque iteration, là ou l'on a :

startOffset = token.startOffset();
endOffset = token.endOffset();

Ca veut dire en fait :

startOffset = the_same_startOffset_than_before;
endOffset = the_same_endOffset_than_before;

Si le token n'est *pas* dans la requête, je vais donc arriver dans le else :

else {
  char[] chars = tokenText.toCharArray();
  if (chars != null)
    this.xmlConsumer.characters(chars, 0, chars.length);
}

Ainsi, on va envoyer *plusieurs* fois le même texte au consumer.

Bon, c'est vrai on va aussi envoyer plusieurs fois 
highlightTerm(tokenText, termText), ce qui va nous créer des trucs comme 
ça :

<sdx:highlight no="1" term="match1">original</sdx:hightlight>
<sdx:highlight no="2" term="match2">original</sdx:hightlight>
<sdx:highlight no="3" term="match3">original</sdx:hightlight>

2 problèmes :
1) l'augmentation du compteur (au fait, quel en sont les usages 
potentiels ?)
2) la répétition inutile (et problématique) du text() original.

Ne peut-on concevoir :

<sdx:highlight no="1" terms="match1 match2 match3">

ou

<sdx:highlight no="1" term="match1">
  <sdx:highlight no="2" term="match2">
    <sdx:highlight no="3" term="match1">
original
    </sdx:hightlight>
  </sdx:hightlight>
</sdx:hightlight>

En ce qui concerne le parsage de la requête, j'en suis là :

Soit :

token1-1 (positionIncrement = 1)
token1-2 (positionIncrement = 0)
token1-3 (positionIncrement = 0)

token2-1 (positionIncrement = 1)
token2-2 (positionIncrement = 0)

La seule (?) façon d'interpréter correctement la Query, c'est de faire 
la combinatoire, i.e. :

BooleanQuery
-- OR -- PhraseQuery "token1-1 token2-1"
-- OR -- PhraseQuery "token1-2 token2-1"
-- OR -- PhraseQuery "token1-3 token2-1"
-- OR -- PhraseQuery "token1-1 token2-2"
-- OR -- PhraseQuery "token1-2 token2-2"
-- OR -- PhraseQuery "token1-3 token2-2"

Ou, en jargon Lucene :

"token1-1 token2-1" "token1-2 token2-1" "token1-3 token2-1" "token1-1 
token2-2" "token1-2 token2-2" "token1-3 token2-2"

Bref, je ne vois pas en quoi une modification du queryParser peut 
garantir l'unicité du passage dans la boucle du highlighter. Mais 
peut-être ai-je loupé quelque chose ?

>  >Je travaille sur un tokenizer qui, pour un token en entrée, peut en
> renvoyer N en sortie. Evidemment, ces N tokens ont
>  >les mêmes offsets que le token d'entrée. La seule différence, c'est
> que le premier a un positionIncrement de 1 (cas 
>  >standard) et les autres un positionIncrement de 0.
>
> Tu l'as vu? Ça ne t'aide pas?:

Euh... quoi ? La doc Lucene ? Bien sûr :-) La problème, c'est que les 
implémentations travaillent toutes avec des getPositionIncrement de 1 
(il y a néanmoins un excellent test dans 
src/test/org/apache/lucene/search/ mais il n'implique pas le queryParser 
:-() . On reparler de TermVectors, mais j'ai bien peur qu'il faille 
attendre...

A+

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