Re: [sdx-developers] RE : SDX 2 : implantation des entrepots de documents

[Pierrick Brihaye]

Salut,

----- Message d'origine ----- 
De : "Martin Sévigny" <address@hidden>


Bonjour,

>La recherche ne sera pas initiée par une base de documents. Pourquoi?
>Parce que la recherche sera multibase.

Euh... qui initie la requête dans ces conditions ? Et ensuite, qui récupère les 
résultats ? Qui les assemble quand ils ont de multiples provenances ? Un 
servlet/une XSP de niveau supérieur (du style de ce qu'est Cocoon à SDX) ?

>En SDX 2, je pensais que l'on pourrait indiquer quelles bases
>on veut chercher. Je ne sais pas encore si on va passer directement les
>objets DocumentBase , directement des Searcher Lucene ou un autre objet
>du genre, c'est à voir. Qu'en penses-tu?

Ben... en guise de préliminaire, il y a  à mon avis désormais plusieurs types 
de requêtes possibles . La requête Lucene, bien sûr (on pourrait l'appeler 
"requête documentaire") mais on a aussi, si on utilise une base XML les 
possibilités de requêtes natives (ça remplacerait pas mal des appels aux 
servlets dans mon appli). Je passe sur d'éventuelles requêtes spatiales, SGDB 
ou autres (j'ai quelques idées là-dessus)... Du coup, je ne sais plus trop :-)

C'est un peu ce que je voulais dire en proposant d'injecter les requêtes aux 
repositories (à eux de voir s'ils peuvent les traiter ou pas, ce qui est un 
autre problème). L'important étant que les résultats retournés soient conformes 
à une structure donnée (via une interface SDXResultImpl ou similaire...)

En fait j'ai parfois du mal à saisir la différence *fonctionnelle* entre une 
base et un repository car je conçois qu'on puisse avoir, pour une même base, 
plusieurs repositories de *même type* (p.e. un sur une machine X - 
éventuellement en maintenance - en MySQL, l'autre sur une machine Y - 
éventuellement plantée - en XIndice). Je reste à ton écoute pour préciser ça 
car, pour l'instant, je comprends dans ce que tu proposes que la base reste 
*seule* responsable de l'indexation (documentaire), de la résolution des 
requêtes et de la construction des résultats et, qu'en gros, c'est un pôle qui 
s'accapare toute les fonctionnalités de ce type et ne laisse rien aux autres...

Mais bon, si on se cantonne à des requêtes Lucene, autant dans ce cas utiliser 
l'infrastructure Lucene à mon avis... si ça peut aider à l'améliorer ;-))

>Pour les résultats, je continuerais à les faire gérer par un objet de
>résultats.

Oui, c'est très bien. Je reste sur ma proposition d'implanter une 
reconstruction à la demande de ces résultats, mais ce n'est pas contradictoire 
avec cette approche (mise en mémoire de résultats partiels vs mise en mémoire 
de résultats complets dans SDX1).

> Pour le multithreading, je le vois essentiellement pour deux tâches :
>- indexation
>- recherche

Essentiellement, mais c'est à préciser : il y a beaucoup d'étapes dans ces deux 
concepts. Prévoir également des synchronisations sur toutes les fonctions 
accédant aux repositories, mais bon, ça existe déjà dans SDX1.

> Je vois. Peux-tu donner un exemple plus précis, ça m'intrigue. Que
> doit-on donner comme information au listener : quels documents sont
> indexés?

Voici un exemple pour un afterIndexing (ou before) : je fais une première 
transformation qui va me chercher l'info géométrique (ça ne concerne qu'un ou 
deux éléments) et j'alimente un shapefile avec un objet spécifique créé à 
partir de la string issue de ma transformation. Quand je détruis le document, 
j'ai vais détruire son entrée dans le shapefile via beforeDelete (avec rollback 
et tout le toutim en cas de problème). En fait, même l'indexation Lucene 
pourrait bénéficier de cette infrastructure.

Je pense aussi à une fonctionnalité qui me plairait pas mal : implanter des API 
CVS pour gérer un historique des versions lors d'un beforeInsert, 
beforeUpdate... J'ai pris l'habitude de passer les fichiers XML livrés dans la 
distrib SDX dans un diff visuel. Ca jette :-) et ça ouvre des perspectives 
assez intéressantes de GED.

A+

p.b.