[sdx-developers] documentbase

[Pierrick Brihaye]

Salut,

J'ai pas mal travaillé sur ce package. Aucune modification dans le code, mais 
pas mal d'ajout/correction de commentaires et quelques TODO. Mais bon, j'hésite 
à faire un commit :-)

Le plus gros problème qui se pose pour moi - en tant que développeur ! -, c'est 
la terminologie employée. Entre celle héritée de Lucene et celle, plus 
traditionnelle, issue des "bases (de documents)", on s'emmèle parfois les 
pinceaux !

Je prends un exemple : l'interface Repository propose "add/delete", ce qui me 
paraît logique dans la mesure où un Repository s'occupe d'ajouter et détruire 
*physiquement* un document.

DocumentBase propose "index/delete". Ici, de deux choses l'une :

- ou on postule que c'est la même terminologie qu'un repository, une 
DocumentBase ayant comme mission 
*supplémentaire* de faire de l'indexation avant de déléger les manipulations 
physiques aux Repositorys. Dans ce ce cas, "index" pourrait être remplacé par 
"add".
- ou l'on postule que l'indexation est la mission première d'une DocumentBase 
et, dans ce cas, pourquoi ne pas utiliser "deindex" ou "unIndex" en lieu et 
place de "delete" ?

Par ailleurs. La DocumentBase travaille sur 3 choses :

- communication avec les Repositorys. Normal.
- indexation pour la recherche : sdxLuceneSearchDir, sdxSearchIndexDir, lIndex, 
SEARCH_INDEX_DIRECTORY_NAME. Ici, on pourrait peut-être harmoniser sur la base 
de "SearchIndex", non ?
- indexation pour un stockage des références (que je préfèrerais appeler 
"métadonnées" ; je pense que j'en reparlerai) : sdxRepoIndexDir, 
sdxRepoIndexDB, DOCUMENTBASE_DIR_PATH. Ici aussi on pourrait harmoniser, mais 
sur une base à mon avis plus parlante : "ReferencesIndex" ou "MetadataIndex".

A ce propos, dans l'appli sdxworld, j'ai :

sdx
- sdxworld
-- conf
--- dbs
---- apps
----- documents
------_lucene
------- doc
----- sdx-repo-index
----- sdx-search-index
--- users
-- css
-- documents
-- xsl

J'avoue que j'ai du mal à suivre :
- voir "apps" sous "dbs" : si "dbs" s'appelait "repository" ou "repository1" ou 
"FirstRepository", ça serait plus clair car, logiquement, c'est un "app" qui 
contient des "dbs" et pas l'inverse, non ? Je sais bien, que tout ça, c'est de 
la String et qu'on pourrait avoir "klmklmklmk" mais quand même, ça jure dans 
une appli d'exemple !
- qu'est ce que c'est que ce répertoire "doc" ? Il contient des index Luicene 
mais lesquels ?

Pour continuer sur "DocumentBase", je crois qu'il y a un défaut potentiel dans 
l'implémentation. En effet, quand on ajoute (indexe ;-) un document :
1) On écrit l'index de recherche
2 On écrit le document dans le repository 
3) On écrit sa référence

Je pense que dans cette section où tout rollback est difficile à implémenter, 
il serait préférable de passer en premier les actions ayant le plus de gravité 
en cas d'exception :
1) Ecrire le document dans le repository
2) Ecrire sa référence
3) Ecrire l'index de recherche

En effet, en cas de problème, on peut toujours recréer un index de recherche 
et, éventuellement et après un scan des documents dans les repositorys, recréer 
une référence, l'inverse n'étant pas vrai.

Raisonnement strictement inverse pour "delete", quoi que dans ce cas, on peut 
discuter. Actuellement, on a :
1) Destruction dans le repository
2) Destruction de la référence
3) Destruction de l'index de recherche

On pourrait avoir, toujours dans la même perspective où l'on disposerait de 
tâches de réparation de l'intégrité :
1) Destruction de l'index de recherche
2) Destruction de la référence
3) Destruction du document dans le repository

Voilà pour l'instant. Je me propose de mettre en oeuvre ce que je viens 
d'écrire. Cependant, je ne compte pas dans un premier temps aller trop loin de 
façon à pas toucher au nom des éléments/attributs dans les fichiers de 
configuration et ainsi obliger à un repackaging des applis.

Pierrick Brihaye
mailto:address@hidden