[sdx-developers] Etat des questions

[Pierrick Brihaye]

Salut,

Voici mon état des questions en ce vendredi ; probablement également mon 
programme du WE :-)

J'ai revu le code qui génère <sdx:query>. L'objectif est d'avoir un 
attribut LuceneQuery qui est reparsable, i.e. dont le champ par défaut 
est *réellement* le champ par défaut de la fieldList. J'ai fait quelques 
tests... ça tourne. Commit ?

En ce qui concerne le QueryParser, j'espère que j'ai convaincu ;-) : il 
me reste un truc à voir :

| term=<QUOTED>
       [ slop=<SLOP> ]
       [ <CARAT> boost=<NUMBER> ]
       {
         q = getFieldQuery(field, analyzer,
                           term.image.substring(1, term.image.length()-1));
         if (slop != null && q instanceof PhraseQuery) {
           try {
             int s = Float.valueOf(slop.image.substring(1)).intValue();
             ((PhraseQuery) q).setSlop(s);
           }
           catch (Exception ignored) { }
         }
       }

Si les tokens ont la même position, ce code ne sera jamais appelé car on 
n'a plus une PhraseQuery mais une BooleanQuery dont les clauses sont, 
effectivement, des PhraseQuery ; il faudrait donc leur appliquer le slop 
individuellement.

Je compte également intégrer un élément <sdx:query> dans 
<sdx:navigation>. IMHO, ça ne mange pas de pain mais ça me serait utile.

Il faut aussi que je revoie la fonction sdx_dir implémentée dans les 
logicsheets : toujours pas compris le test sur la taille des vecteurs.

Je propose également d'avoir un flag "recursive" sur les paramètres 
@dir. Certes, ça pourrait être géré par une meilleure prise en compte 
des include/exlude (avec des patterns du style "**").

Je vais également rédiger un Reader de documents SDX qui prendrait des 
paramètres du genre app, db, repo, id...

Je vais investiguer sur le fait que la UnanalyzedQuery ne renvoie pas le 
bon LuceneQuery, i.e. field:|non token|, actuellement field:non token 
(qui est donc non reparsable).

Je vais repackager l'analyseur arabe et donc éviter la dépendance à 
Lucene. Ca n'empêche qu'il faudra toujours patcher le jar Lucene si l'on 
veut disposer de l'UnanalyzedQuery.

Des commentaires ?

A+

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