[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE : [sdx-developers] documentbase
From: |
Pierrick Brihaye |
Subject: |
Re: RE : [sdx-developers] documentbase |
Date: |
Mon, 10 Jun 2002 15:09:31 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 |
Salut,
Martin Sévigny wrote:
Quelques commentaires rapides pour l'instant.
OK. Après y avoir regardé d'encore plus près, je crois que ces
commentaires devront devenir plus fournis... :-)
- 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" ?
Je préfère cette option.
Comme tu veux...
Ca peut être inversé. Mais il faut tout de même commencer par la
transformation d'indexation, pour avoir l'identifiant du document.
On est d'accord.
Bon, voilà le fruit de mes réflexions :
Une DocumentBase fait donc trois choses :
1) elle délègue le stockage du document au repository ad hoc
2) elle indexe le document (deux phases : la génération du document
d'indaxtion et la sauvegarde de l'index)
3) elle maintient un index interne pour savoir quel document est dans
quel repository.
Pour moi, cet index interne pourrait s'appeler "métadonnées système". On
pourrait y trouver le timestamp de l'ajout, de la modif, de la
suppression (?), de la dernière indexation... Pour cette dernière
métadonnée, ça serait très pratique pour organiser une (ré)indexation en
tâche de fond...
Le stockage du document est dépendant du repository. On a donc ici
quelque chose de très générique. Bien !
Là où ça change c'est, sur le stockage de l'index et sur le stockage des
métadonnées système qui sont dépendants des architectures sous-jacentes.
Aussi, je me demande on ne ferait carrément pas mieux de concevoir une
interface SearchIndexManager avec une classe LuceneSearchIndexManager.
Idem pour un LuceneSystemMetadataManager, bien sûr
Je trouve en effet que le code est trop encapsulé et qu'il m'empêche
d'avoir des gestionnaires d'évènements aussi performants que je le
souhaiterais.
Du coup, la DocumentBase rédeviendrait générique et on n'aurait plus
besoin de l'interface et de la classe abstraite.
Je crois franchement qu'un tel redéploiement est stratégique et opère
une avancée notable par rapport à SDX 1. Ca permet, pour ceux que ça
intréssarait, davoir ses documents sur un filesystem, ses métadonnées
dans MySql et son index sur un répertoire Lucene.
J'attends donc avant de faire mon commit. J'attends aussi votre réponse
avant de proposer un package conforme à ce que je propose. Je comprends
bien qu'il y a du boulot, mais le jeu en vaut probablement la chandelle
: une DocumentBase risque d'être appelée à faire pas mal de choses...
--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
- [sdx-developers] documentbase, Pierrick Brihaye, 2002/06/08
- RE : [sdx-developers] documentbase, Martin Sévigny, 2002/06/10
- Re: RE : [sdx-developers] documentbase,
Pierrick Brihaye <=
- [sdx-developers] RE : documentbase, Martin Sévigny, 2002/06/10
- Re: [sdx-developers] RE : documentbase, Pierrick Brihaye, 2002/06/10
- Re: [sdx-developers] RE : documentbase, Pierrick Brihaye, 2002/06/10
- RE : [sdx-developers] RE : documentbase, Martin Sévigny, 2002/06/11
- Re: RE : [sdx-developers] RE : documentbase, Pierrick Brihaye, 2002/06/11
- RE : RE : [sdx-developers] RE : documentbase, Martin Sévigny, 2002/06/11
Re: [sdx-developers] documentbase, Frédéric Glorieux, 2002/06/11