RE : [sdx-developers] RE : documentbase

[Martin Sévigny]

Salut,

> Mmmh... je ne crois pas. Quand on est dans une 
> LuceneDocumentBase, on stocke l'index de recherche avec 
> Lucene *et* les métadonnées sytème également avec Lucene. 

Parce qu'il n'y a pas d'autre implantation actuelle pour les
métadonnées...

> <sdx:documentBase id="apps" default="true">
>   <sdx:systemMetadataRepository type="jdbc"/>
>   <sdx:searchIndexRepository type="lucene"/>
>   <sdx:repositories>
> ... rien à changer ici ; c'est *très bien *
>   </sdx:repositories>
> </sdx:documentBase>

... C'est exactement ce qui est prévu. Le nom "LuceneDocumentBase" vient
qualifier le type d'engin de recherche (Lucene), pas le type d'engin de
métadonnées.

Là où on se rejoint pas (je crois), c'est sur l'intérêt d'avoir une
interface DocumentBase. Je m'explique. L'un des rôles d'une base de
documents, c'est de _permettre_ les recherches, en mettant à disposition
un index de recherche. Cet index de recherche pourrait être fort
différent d'un moteur à un autre, par exemple pour une recherche Xpath
dans un moteur XMLDB, on a simplement besoin d'une collection
représentée par une URL.

C'est pourquoi la définition d'une base de documents de type Lucene
comporte des champs, alors que la définition d'une base de documents de
type XMLDB comporterait des index définis par des Xpath, ces index étant
(comme en SQL) une façon d'accélérer les recherches, rien de plus.

Je ne vois pas comment une même classe pourrait gérer à la fois des
index de recherche de type Lucene et des bases XMLDB.

> Euh... c'est le repository qui serait sous MySQL et, 
> effectivement, il y a une classe pour ça qui m'a l'air d'être 
> au point. Les métadonnées, j'aimerai effectivement les mettre 
> sous MySQL qui sait en principe convenablement les gérer. En 
> revanche, pour l'index de recherche, Lucene reste pour 
> l'instant le meilleur.

MySQL sait correctement les gérer... Mais attention aux occurrences
multiples ;-)

> J'ai bien compris, mais telle que cette classe est foutue, 
> toute nouvelle classe nécessitera pas mal de codage car cette 
> classe a à gérer non seulement la délégation aux repositories 
> (ce qui est simple) mais également la création du document 
> d'indexation, son mapping sur une architecture et la gestion 
> des métadonnées sytème. Pour faire court, là où il y a une 
> seule classe, j'en voudrais 3 (voire 4 si l'on considère que 
> génération du document XML d'indexation et mapping du 
> searchIndex sont deux choses différentes). Que cela ne fasse 
> pas peur : tout ce code existe déjà !

Oui, mais si je reprends mon scénario de base de documents XMLDB, on n'a
pas besoin de transformation d'indexation, tu vois? Alors je pense que
oui ce code est spécifique à une base de documents Lucene, ou plutôt à
une base de documents où l'utilisation de la structure se fait a priori.

Donc il faudrait une sous-interface APrioriDocumentBase ? ;-)

> J'ai bien saisi et je suis effectivement persuadé que de 
> sotcker le XML d'indexation *en natif* (d'où l'idée de 4 
> classes) devrait apporter de la performance. J'attends avec 
> impatience le match contre Lucene !

Ah! Tu pense que de stocker le XML d'indexation en XMLDB apportera
quelque chose? Mais non. Dans les implantations actuelles (Xindice) :

- pas de support UTF-8 !!!
- pas d'analyses de mots
- pas de tri de pertinence
- moins de performance

Je ne vois aucun intérêt, à court ou moyen terme.

A bientôt,

Martin Sévigny