Re: [sdx-developers] RE : documentbase

[Pierrick Brihaye]

Salut,

>> 1) elle délègue le stockage du document au repository ad hoc

>> Ad hoc? C'est-à-dire? En fait, lorsqu'on indexe (ajoute...), on doit
>> dire à la DB quel repository utiliser.

On est d'accord. Le repository prend le stockage des documents en charge ; 
c'est une bonne séparation des tâches...

>> Là où ça change c'est, sur le stockage de l'index et sur le 
>> stockage des 
>> métadonnées système qui sont dépendants des architectures 
>> sous-jacentes.
>> 
>> Aussi, je me demande on ne ferait carrément pas mieux de 
>> concevoir une 
>> interface SearchIndexManager avec une classe LuceneSearchIndexManager.

>Je ne comprends pas. C'est déjà le cas avec Database et LuceneDatabase,
>non?

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. Ce que je voudrais, c'est une *délégation* du style de celle des 
repositories que, je le répète, trouve excellente. On pourrait avoir un 
LuceneMetadataManager (qui à l'heure actuelle est complètement encapsulé dans 
la LuceneDocumentBase), un JDBCMetadataManager etc. De le même façon, on 
pourrait avoir également un LuceneSearchIndexManager (encapsulé lui-aussi), un 
JDBCSearchIndexManager...

L'avantage serait :
- de ramener la classe DocumentBase à une classe indépendante des architectures 
sous-jacentes. Plus besoin d'interface ni de classe abstraite...
- de pouvoir disposer d'un système d'évènements bien plus fin. En l'état actuel 
des choses, il m'est très difficile de transmettre à un gestionnaire 
d'évènements le XML résultant de la XSL d'indexation.
- de permettre, pour ceux que ça intéresserait, de stocker différentes choses 
sur différentes architectures.

Note : dans un premier temps, une architecture Lucene serait selon moi 
suffisante !

Pour être plus démonstratif :

au lieu de :

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

j'aimerais :

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

Les noms sont bien sûr indicatifs ! Mais bon, pour moi, on a un modèle :

<!ELEMENT documentBase (systemMetadataRepository, searchIndexRepository, 
repositories+)>

> Si tu veux stocker des métadonnées en MySQL, alors tu développes
> une classe MySQLDatabase qui implante Database. Ensuite on permet de
> configurer (dans app.xconf) quel type de gestionnaire de métadonnées
> utiliser. Ce n'est pas suffisant?

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.

>Je ne sais pas si tu veux unifier la recherche documentaire effectuée
>avec Lucene avec la gestion de métadonnées gérée par l'interface
>Database, mais pour moi ça ne devrait pas.

Non, non. Sois sans crainte à ce sujet.

> SDX est un outil de recherche, et la DocumentBase est justement ce lieu
> qui est cherchable. Pour l'instant, le seul moteur de recherche est
> Lucene, mais éventuellement il y en aura d'autres. D'où l'idée de
> l'interface et de la classe abstraite.

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à !

> Par exemple, il sera assez facile d'ajouter une classe XMLDBDocumentBase
> qui fera des recherches Xpath dans un entrepôt de type XMLDB. Un jour
> qu'il y aura un bon moteur XMLQuery, on l'implante, etc. Et SDX peut
> donc intégrer différents moteurs de recherche, l'élément commun étant
> justement cette interface DocumentBase.

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 !

> L'architecture actuelle est justement prévue pour cela. Je ne comprends
> pas ce qui manque (à part des trucs à implanter).

J'espère avoir été clair. Si ce n'est pas le cas, je vous derai un 
éventuellement un dessin montrant une classe DocumentBase délégant à 3 types de 
repositories pouvant les uns et les autres s'appuyer sur des architectures 
différentes...

p.b.