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

[Pierrick Brihaye]

Re,

Rasik Pandey a écrit:

>  Application.USER_DOCUMENT_BASE_ID = "sdxuserdb";
>
> Un nom reservé....

Oui, on est bien d'accord :-)

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

OK. C'est le design depuis toujours. Mais je pense que ça peut-être très 
difficile à tracer le jour où, pour une raison ou une autre, un 
développeur en met 2. Tu te souviens la difficulté qu'on a eue à se 
rendre comptre que 2 repos avaient le même nom ?

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

OK :-)

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

OK.

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

Argl. Je ne l'avais pas vu. Pas facile le ViewCVS pour voir les 
commentaires :-) On peut peut-être supprimer ce code et renommer 
indexationPipeline en defaultIndexationPipeline ? Pas important...

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

Si ça peut aider...

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

OK. Pour le pipeline d'indexation mais ma question était plus vaste.

En fait, on pourrait bel et bien avoir 2 types de bases de documents :

1) celles qui confient l'indexation à la base elle-même (comme le fait 
LuceneDocumentBase) et qui, c'est vrai, utilisent un pipeline, qu'il 
soit "par défaut" ou dynamique.

2) celles qui confient l'indexation à un repository comme pourrait 
l'être un repository XMLDB et qui donc, se passent de pipeline ou, 
plutôt, que se passent de pipeline "Cocoon-like". Idem pour des repos du 
genre XML2SQL ou XML2OQL.

Je conçois que ça soit complexe. L'objectif, dans un premier temps, 
serait de séparer le code relatif à l'indexation dans des classes 
dédiées comme celles que j'ai proposées.

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

Euh... et dans quels cas getRepositoryForDocument est différent de 
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) ?
>
> Non, je crois que c'est au DocumentBase car c'est lui qui utilise des
> entrepots, n'est-ce pas?

V. ci-dessus. Pour moi, une documentBase ne devrait avoir à gérer que 
des documents indexables. Les relations inter-documents, attachés où 
autre, participent plus de la logique applicative IMHO. Dans ces 
conditions, il me semble que le gestionnaire des repo devrait être 
l'application. Ici encore, ce n'est pas très important pour l'instant...

A+

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