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

[Pierrick Brihaye]

Martin Sévigny wrote:

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

Cette interface aurait 4 méthodes : insert, update, delete, select pour 
reprendre une terminologie SQL qui a fait ses peuves :-)

Pour ce qui est indexable/searchable, on peut aussi prévoir une 
interface ad hoc...

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

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

> Cette classe permettra aussi de garder une trace de
> l'entrepôt où se trouve un document.


Cela va de soi :-)


> - implantation de l'interface Store et des classes JDBCStore et (si
> nécessaire) MySQL store.


A priori, le delta ne devrait effectivement pas être énorme.


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


> - modification des autres parties du code pour tenir compte de ces
> nouveautés, en particulier DocumentBase, qui aura un immense impact sur
> DBInfo...


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


> Lorsque nous serons capable de faire cela proprement, je crois que
> l'implantation des autres classes ne sera pas trop un problème.


A priori, on est d'accord. Je vois cependant quelques choses à affiner 
(par rapport à SDX 1) :

- 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)
- réindexer en tâche de fond ou, au moins, en avoir la possibilité, ce 
qui impose une journalisation des indexations.
- 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 :-)

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden