sdx-developers
[Top][All Lists]
Advanced

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

Re: [sdx-developers] SearchTransformer..un peu d'aide


From: Pierrick Brihaye
Subject: Re: [sdx-developers] SearchTransformer..un peu d'aide
Date: Thu, 11 Sep 2003 21:18:09 +0200

Bonsoir,

[repassé en texte brut]

>j'essaie en ce moment de faire un cocoon seachIndexTransformer

Question idiote : ce n'est pas un Generator ?! Qu'est-ce qu'il transforme ?

>le but  étant de réécrire le code SDX  pour la recherche qui est fait pour
etre utilisé en taglib , en un transformer

Bonne idée :-)

>(en fait je ne connais pas trop les requetes SDX , linear, term, simple,
complexe... etc)

En gros, dans SDX, on n'a en fait que 3 query ; les autres pouvant se
résoudre par des query plus atomiques.

La fieldQuery : on cherche une valeur dans un champ (v. discussion en cours
; on n'est pas forcément d'accord sur ce que "valeur" veut dire :-)
La simpleQuery : je préfère l'appeler la "parsedQuery" car elle est
décomposée en fieldQueries et, de plus, les valeurs passent dans
l'analyseur.
La complexQuery : qui permet de créer une arborescence de queries ; on en
reparle... car c'est extrêmement puissant.

Bon, on a aussi la dateQuery qui est une FieldQuery un peu particulière....

... et, bien sûr, toutes les autres Query Lucene (WildCard, Fuzzy, Prefix..)
qui, dans SDX, sont confiées au queryParser et donc à la simpleQuery.

Si votre composant est ambitieux, il serait assez comparable à la
complexQuery de SDX. Un truc dans ce goût-là :

<search>
  <!-- les endroits où chercher -->
  <!-- v. MultiSearcher Lucene -->
  <indexes>
    <index id="aaa">
    <index id="bbb">
    <index id="ccc">
  </indexes>
  <!-- une jolie combinaison de requêtes -->
  <group operator="and">
    <search field="ddd" value="xxx"/>
    <group operator="or">
      <search field="eee" value="xxx"/>
      <search field="fff" value="xxx"/>
      <group operator="not">
        <search field="ggg" value="xxx"/>
      </group>
     <search field="hhh" value="xxx"/>
    </group>
    <search field="iii" value="xxx"/>
  </group>
</search>

ou alors, version "on peut tout dire avec une ligne de texte" :
<search>
  <!-- les endroits où chercher -->
  <!-- v. MultiSearcher Lucene -->
  <indexes>
    <index id="aaa">
    <index id="bbb">
    <index id="ccc">
  </indexes>
  <!-- la même que la précédente -->
  <!-- si je ne me suis pas trompé -->
  <parsedQuery parser="org.truc.queryParser">
+ddd:xxx +(eee:xxx fff:xxx -(ggg:xxx) hhh:xxx) +iii:xxx
  </parsedQuery>
</search>

L'idéal étant, bien sûr, de pouvoir tout faire en même temps (ce qui est
relativement simple).

Voilà en gros les données du problème... on voit que le gros truc, c'est le
passage de paramètres. Ici, on peut tout imaginer, depuis des trucs du genre
sitemap ou d'envoyer les differentes query dans le flux auquel cas, je le
reconnais, votre composant serait effectivement un transformer.

>cela comble t'il tous les cas d'utilisation ? (aurais je oublié un cas
important)

Je pense que ça le fait :-)

>- en sortie  je me baserais sur le seachGenerator de cocoon (xmlisation des
resultats, gestion de la pagination)  (peut être que le développement dans
>SDX est mieux)

C'est à comparer.

>j'aurais juste voulu avoir une petie aide concernant votre code:
> - savoir pourquoi avoir écrit un queryparser , autre que celui proposé par
lucene

Je ne suis pas le mieux placé pour répondre : le gros intérêt, ce sont les
pipes ("|") qui disent au parseur de ne pas analyser ce qu'il y a dedans. Il
y a peut-être également quelques bricoles sur la tokenization, plus
francophone.

> - qu'est que le Criteria Filter ?

C'est un... critère de filtre. Rappelons qu'un filtre est appliqué *après*
l'exécution de la requête. De quoi vous donner des idées pour un
ResultsTransformer alimenté par le SearchGenerator/Transformer :-)

A bientôt,

p.b.






reply via email to

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