sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-developers] DocumentBase et Cie : derniers commits


From: Pierrick Brihaye
Subject: [sdx-developers] DocumentBase et Cie : derniers commits
Date: Mon, 05 Jan 2004 12:15:49 +0100
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02

Re,

Je vois que ces classes se clarifient :-)

Quelques problèmes potentiels cependant :

Dans SDXDocumentBase, on a 2 setId (pour les bases de documents et pour la base utilisateurs) : qu'est ce qui garantit que ces Id sont uniques dans l'application ?

On a :
Configuration userDbConf = configuration.getChild(ELEMENT_NAME_USER_DOCUMENT_BASE, false);

Quid si on a plusieurs enfants ELEMENT_NAME_USER_DOCUMENT_BASE ? Problèmes de design d'application en perspective...

Design :

Ne peut-on factoriser :
Configuration[] repoConfList=getRepositoryConfigurationList(configuration);

et :

this.configureRepositories(repoConfList);

... et libérer ainsi plus vite repoConfList ?

Un truc spécifique à Lucene :

props.put(LuceneDocumentBase.DOCUMENTBASE_DIR_PATH, dbDirPath);

... deplacer la déclaration ?

configurePipeline (à renommer en configureIndexationPipeline ?) renvoie à la classe AbstractDocumentBase. 2 problèmes ici :

if (pipeConf == null) {
  exception
}

Dans la mesure où l'on peut définir dynamiquement un pipeline, est-ce qu'un pipeline "par défaut" est *obligatoire*. On pourrait peut-être se contenter d'un warning dans les logs du style "no default indexation pipeline for this document base" ?

Autre point là-dessus. Imaginons une DB XML comme eXist qui dispose de son propre moteur d'indexation (paramétrable). Doit-on encore une fois imposer un pipeline d'indexation ? Est ce que l'indexation via un pipeline que propose SDX ne doit pas être déférée à une classe spécifique du genre :

SDXHandledIndexationDocumentBase (qui utilise LuceneOrWatheverIndex)
vs.
DeferredIndexationDocumentBase ?

... et, confier à cette base, plutôt qu'au document, la gestion des fields ?

Un truc que je n'ai pas bien compris :
quelle est la différence entre getRepositoryForDocument et getrepositoryForStorage ?

Par ailleurs, dans la mesure où on peut avoir des repos d'application. N'est-ce pas à cette classe de gérer les connections (et le pool) ?

Voilà. Quelques idées pour améliorer le design. Pour les archives et... pour mes WE :-) Votre avis est cependant bienvenu.

A+

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]