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

[Martin Sévigny]

Bonjour,

> > Il faut aussi comprendre qu'il y aura une classe 
> "DocumentBase" qui aura
> > des méthodes (parmi d'autres) pour ajouter un document ou un lot de
> > documents, pour supprimer un document ou un lot de documents, pour
> > réindexer, etc.
> 
> 
> Euh, plutôt qu'une classe, on ne peut pas prévoir une interface 
> qu'implémenteraient SDXDocument, SDXAttachedDocument, 
> SDXTabularData... ?

Pour moi c'est autre chose. En fait, je n'ai pas eu l'occasion de le
terminer, mais j'ai aussi commencé à préparer un message concernant la
séparation conceptuelle dans SDX v2 entre une application et une base de
documents. Une applicaiton pouvant avoir plusieurs bases de documents,
une base de documents pouvant utiliser plusieurs entrepôts.

L'objet DocumentBase dont je parle (que ce soit une interface ou une
classe pour l'instant ça ne me chicote pas beaucoup) représente ce
concept de base de documents.

> Dans ton approche, c'est apparemment l'entrepôt qui gère les 
> I/O. Dans 
> la mienne, ce sont les objets eux-même. Mais bon, je pense 
> que les deux 
> approches se valent...

Moi aussi je pense. Je me rappelais de tes commentaires à ce sujet, et
j'ai hésité un peu, mais finalement j'ai trouvé que ça m'était plus
naturel de le faire en entrepôts. Les documents, je voulais les garder
indépendants de la notion de stockage. Mais bon, je crois que les deux
approches se défendent.

> Ceci dit, les approches ne sont pas réellement contradictoires : un 
> SDXDocument peut tout à fait déléguer son insert à l'insert de 
> l'entrepôt. Ca fait un peu plus de "cablage", mais ça me 
> paraît garantir 
> plus facilement la réutilisabilité du code...

On peut faire cela, mais je ne vois pas en quoi c'est plus réutilisable.

> > - implantation de la classe DocumentBase et de ses méthodes 
> d'ajout, de
> > suppression et de consultation de documents
> 
> 
> Euh... DocumentBase, c'est en fait un SDXDocumentRepository ?

Si on veut. Ce sera un objet qui encapsulera un index lucene et des
entrepôts. Il offrira des méthodes de recherche, d'ajout
(individuellement, en lots, etc.).

> ... qui a bien besoin d'être nettoyée :-)

En fait, je crois qu'elle va disparaître. Ca c'est du nettoyage!

> - possibilité d'encapsuler les index dans un SGBD (j'ai vu passer un 
> SQLRepository chez Lucene mais je ne sais pas ce qu'il vaut)

Ouais, je te le laisse celui-là... Voir plus loin.

> - réindexer en tâche de fond ou, au moins, en avoir la 
> possibilité, ce 
> qui impose une journalisation des indexations.

Réindexer, mais aussi indexer, voire chercher, en toile de fonds. Sur
commande, bien sûr. C'est prévu.

> - stockage des résultats de requêtes dans un SGDB (R ou XML) pour 
> optimiser la gestion de la mémoire (confiée au SGBD). On a là 
> un goulot 
> d'étranglement assez prononcé. Note : ce dernier pourrait tout à fait 
> implémenter l'interface dont je parlais plus haut :-)

Je constate que tu proposes des choses qui ont tendance à augmenter
l'importance du SGBD, R ou XML. C'est drôle, car hier soir je me disais
justement qu'on pouvait très bien s'en passer totalement. J'ai toujours
eu en tête de ne pas obliger l'utilisation d'un SGBDR en SDX v2, mais
d'obliger l'utilisation d'un SGBD XML. Mais à bien y penser, je ne suis
pas convaincu qu'il s'agisse d'une bonne idée.

Le SGBDR fait ceci en SDX v1 : entrepôt de documents attachés et
normaux, liste des utilisateurs, liste des privilèges, liste des bases
de documents, liste des groupes, liste des appartenances
Groupes/Utilisateurs. Si on oublie l'entrepôt discuté auparavent, on a
ici des bases (qui deviendront des applications), des utilisateurs et
des groupes, le reste c'est des relations entre tout cela.

Nos trois objets ont une représentation XML, et il serait étonnant qu'on
en ait des milliers par application, alors je me disais que l'on
pourrait les stocker en fichiers et les indexer en lucene (une base
d'administration). Donc plus nécessité d'un SGBDR. On en utilise un si
on le veut, pour entrepôt par exemple. En terme de facilité
d'installation, on a un gain énorme.

Mais bon, je n'y ai pas encore réfléchi à fonds.

A bientôt,

Martin Sévigny