[Top][All Lists]
[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
- [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- RE : [sdx-developers] DocumentBase et Cie : derniers commits,
Rasik Pandey <=
- Re: RE : [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- Re: RE : [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- Re: RE : [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- RE : RE : [sdx-developers] DocumentBase et Cie : derniers commits, Rasik Pandey, 2004/01/05
- Re: RE : RE : [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- RE : RE : RE : [sdx-developers] DocumentBase et Cie : derniers commits, Rasik Pandey, 2004/01/05
- Re: RE : RE : RE : [sdx-developers] DocumentBase et Cie : derniers commits, Pierrick Brihaye, 2004/01/05
- RE : RE : RE : RE : [sdx-developers] DocumentBase et Cie : dernierscommits, Rasik Pandey, 2004/01/05