sdx-developers
[Top][All Lists]
Advanced

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

RE : [sdx-developers] DocumentBase et Cie : derniers commits


From: Rasik Pandey
Subject: RE : [sdx-developers] DocumentBase et Cie : derniers commits
Date: Mon, 5 Jan 2004 13:09:54 +0100

Salut,

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

 Application.USER_DOCUMENT_BASE_ID = "sdxuserdb";

Un nom reservé....

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

On ne doit pas avoir plusiers, si oui on prend la premiere delcaration.

 >Design :
 >
 >Ne peut-on factoriser :
 >Configuration[] 
 >repoConfList=getRepositoryConfigurationList(configuration);
 >
 >et :
 >
 >this.configureRepositories(repoConfList);
 >
 >... et libérer ainsi plus vite repoConfList ?
 
C'est fait.

 >Un truc spécifique à Lucene :
 >
 >props.put(LuceneDocumentBase.DOCUMENTBASE_DIR_PATH, dbDirPath);
 >
 >... deplacer la déclaration ?
 
C'est fait.


 >configurePipeline (à renommer en configureIndexationPipeline ?)

Configuration pipeConf = configuration.getChild(ELEMENT_NAME_INDEX,
true).getChild(ELEMENT_NAME_PIPELINE, false); 
------------------------------------------------------------------------
-----------^^^^^^^^^^^^^^^^^^^^^
 
>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*. 
 

Ce code est commenté depuis SDX 2.0 ou SDX 2.1 donc un pipeline "par
défaut" N'est PAS *obligatoire*

 >On pourrait peut-être se 
 >contenter d'un warning dans le logs du style "no default indexation 
 >pipeline for this document base" ?

Si tu veux..?

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

Trop complexe? Et, Ce n'est pas nécessaire. Vois mes remarques dessus.

 >Un truc que je n'ai pas bien compris :
 >quelle est la différence entre 
 >getRepositoryForDocument et 
 
 L'entrepot dans lequel le document est stocké.

 >getrepositoryForStorage ?

 On fait un "lookup" dans le Hashtable "repositories" pour l'entrepot
dans lequel on va stocké le document.

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

Non, je crois que c'est au DocumentBase car c'est lui qui utilise des
entrepots, n'est-ce pas?


Rasik





reply via email to

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