RE : [sdx-developers] Etat des questions

[Rasik Pandey]

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 ?

Tu as testé quels cas?

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

Je ne suis toujours pas convaincu mais on va le revisiter bientôt.


 >| 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 "**").

Tu vas implanter le premier ou le deuxième ou les deux?

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

OK. 

 >
 >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).

OK.


 >Je vais repackager l'analyseur arabe et donc éviter la dépendance à 
 >Lucene.

Super, ça sera plus facile à gérer les "jars".
  
 >Ca n'empêche qu'il faudra toujours patcher le jar Lucene si l'on 
 >veut disposer de l'UnanalyzedQuery.

Tu peut nous donner plus d'info ici.



Rasik