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

[Martin Sévigny]

Bonjour,

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

C'est l'Application. Avec un grand A. Je n'ai pas fini de rédiger mon
point de vue là-dessus, mais il ne faut pas oublier que j'avais prévu
une hiérarchie

Framework ( = installation SDX)
  Application (plusieurs par installation)
    Base de documents (plusieurs par application)
      Entrepôt (plusieurs par base de documents)

En SDX 1, Application = Base de documents = Entrepôt.

Par exemple, en XSP, je fais

<sdx:executeSimpleQuery queryParam="q"/>

Le framework identifiera la bonne application (celle où se situe la
XSP), puis on aura quelque chose comme app.getSearchers() que l'on
passera à la requête avant de faire un execute(). Les résultats seront
mis dans le XML dynamique construit par la XSP, comme en SDX 1.

Par la suite, si je fais

<sdx:includeDocument idParam="id"/>

Le framework identifiera l'application, puis on aura quelque chose comme
app.getDocumentAsSAX(id), et alors l'application sera responsable de
trouver la bonne base de documents, puis la base de documents sera
responsabke de trouver le bon entrepôt, puis l'entrepôt de retrouver le
document et de l'envoyer en SAX.

Bien entendu, l'API XSP devra permettre de spécifier dans quelle(s)
bases de documents chercher, par défaut ce sera toutes les bases.

Dans le cas où il y a une base de documents et un entrepôt, on retrouve
le scénario de SDX 1, mais dans une architecture plus souple.

Si on veut implanter une recherche autre que Lucene (par exemple un
Xpath pour une base XML:DB), alors il faudrait avoir un autre type de
requête, pour lesquels on passerait quelque chose comme l'identification
de collections dans les bases XML, et alors on aurait toujours un
execute(), etc.

Donc on aurait une interface SDXQuery (en fait on l'a déjà), avec des
LuceneQuery et des XMLDBQuery. Etc.

Pour cet aspect des requêtes, c'est une première réflexion, je ne sais
pas encore si ça tient la route.

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

Je pense que j'ai précisé : la base est responsable de l'indexation, de
retourner les documents (en demandant au bon entrepôt), et enfin de
fournir les "Searchers" pour l'exécution des requêtes.

En fait, pour moi le principal intérêt d'avoir plusieurs entrepôts, je
l'explique ainsi.

L'une des lacunes de SDX 1 est qu'il doit s'accaparer les documents XML
et les documents attachés pour fonctionner. Dans ton cas par exemple, ça
fait beaucoup de doublons, ça prends de l'espace et ça augmente le
risque d'erreurs sur les versions.

Dans SDX 2, je voulais permettre un entrepôt qui ne duplique pas (sauf
pour cache éventuellement) les documents, et c'est (pour l'instant)
l'entrepôt URLRepository qui joue ce rôle. Les autres entrepôts prévus
(SGBD, XML:DB, système de fichiers) sont à mon sens équivalents car ils
dupliquent tous les documents. Le choix de l'un ou l'autre est une
question de préférence, et en fait il n'y a pas beaucoup d'intérêt
d'utiliser plus d'un entrepôt de ce type.

> 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 l'instant, la seule chose certaine c'est qu'il y aura toujours des
requêtes Lucene en SDX 2. Mais c'est vrai que ça m'intéresse beaucoup
d'avoir des requêtes XML:DB aussi.

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

Petite précision : SDX (1 et 2) ne conserve pas les résultats en mémoire
_sauf_ si on demande un tri. Par exemple, si je fais une requête
sdxall:1 sur une base de 3 millions de documents, ça prend 20
millisecondes et je ne vois aucune augmentation de la mémoire requise.
Si je le trie c'est une autre histoire...

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

En fait, tu veux avoir du WebDAV directement sur SDX? Voir
http://www.webdav.org/ et, peut-être encore mieux, voir le support
WebDAV dans Tomcat 4 et http://www.mucl.de/~jmetzner/xincon/ pour un
test de support WebDAV directement dans Xindice...

A bientôt,

Martin Sévigny