Re: [sdx-developers] RE : Lucene

[Pierrick Brihaye]

Salut,

Martin Sévigny wrote:

> Comme le fait SDX d'ailleurs. Eventuellement, le code de tri sera un peu
> plus proche du coeur de Lucene, ce qui améliorera (peut-être) les
> performances. 


Oui, à voir. En fait, j'ai bien une idée sur la question (vous vous en 
doutiez, non ? ;-) : ce que j'aimerais, c'est une requête Lucène en 
tâche de fond (à priorité haute, bin sûr) qui renvoie ses résultats un 
par un à un composant ad hoc. Bref, du SAL ("simple APIs for Lucene") ;-)

> Mais je n'ai pas essayé le bean.


Je vais essayer de le faire...


> J'ai déjà le code, c'est quelques lignes à changer


Je m'en doute et j'ai vu aussi quelques demandes dans les liste Lucene 
(que M. proxy Culture m'interdit). L'une de mes interrogations était :
- ce genre de chose semble faire l'unanimité
- des patches existent

... et ça ne rentre pas dans le code ! Drôle de gestion de projet.


> > - possibilité de stocker du contenu binaire (non indexé, évidemment)
>
> Ca t'intéresse? Pour faire un LuceneRepository? ;-)


Presque ! En fait, je veux partager mon index Lucene avec d'autres 
applis. Ca me ferait ch... d'avoir à faire 2 indexations différentes, 
même si j'estime qu'à terme cela devra être permis dans SDX.

J'en profite pour faire une feature request : Lucene stocke des String, 
soit. Du coup ça donne le code bizarre des dateFields avec, notamment, 
l'utilisation du terrible MAX_RADIX :-)

Moi, je veux stocker des réels (mais je sais que dans un premier temps, 
je n'échapperai pas à un workaround du style DataField), et puis des 
Strings ayant un format particulier (toute String ne s'y conformant pas, 
génèrerait une exception à l'indexation).

Pour cela, il faudrait que les "champs" puissent mentionner le type de 
Field Lucene de façon plus souple que ce qu'on a actuellement, du genre 
un truc qui ferait un Class.forName() sur un.package.monTypeDeChampLucene.


> Il faudra le faire, il existe déjà du code envoyé par quelqu'un qui
> permet de contourner ce problème.


Vu aussi. Même commentaire sur l'intégration du patch dans le source 
officiel.


> Problème de QueryParser je crois. De toutes, SDX 2 devra avoir son
> propre QueryParser, à moins que Lucene prenne prochainement une
> véritable tendance multilinguiste...


A priori annoncé... J'ai vu quelques fragments de code sur ce sujet.


> C'est un peu ce que nous comptons faire. Très rapidement le code des
> champs multiples sera vraiement testé et dès que c'est fait je leur
> envoie.


C'est marrant, les termes de ta phrase me posent problème. J'ai mis un 
temps fou pour comprendre que Lucene était une base de données... 
possédant elle-même se propres index (isIndexed = true). Or, comme on 
s'en sert pour indexer, ça met une pagaille pas possible dans les termes 
qu'on utilise, du genre "j'indexe un champ de ma base de donénes dans 
une base de données Lucene où il sera stocké comme un champ indexé et je 
le retrouverai sous forme de terme". Le pauvre utilisateur ou 
développeur aurait tout à gagner à disposer d'une liste terminologique 
claire :-)

> > Autre truc : si je veux faire un filter sur un jeu de 
> > résultats, je suis 
> > obligé d'avoir un champ "stored" ?
> Sais pas. Tu l'as constaté?


Non. Mais intuitivement, je le sens comme ça. Pour filtrer, il faut 
avoir une valeur...


> Logiquement, oui pour SDX, mais comme Cocoon le met en optional, il est
> resté là. Si on le déplace, il faudra faire attention aux
> synchronisations avec Cocoon, mais je crois que c'est envisageable.


Oui. Car, sous Netbeans, je monte lib et ça ne compile évidemment pas. 
Intellectuellement, ça me gêne d'avoir à monter "optionnal" pour avoir à 
compiler...


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