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

[Rasik Pandey]

Salut,

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

Pour la documentation, le schema? 

 >>  >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...
 
C'est fait.


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

C'est du SDX 3, non? 
 
 >>  >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 

L'entrepot où un document physique existe deja.

getrepositoryForStorage ?

Au momement de l'indexation, c'est l'entrepot dans lequel on va
sauvegarder le document.

Je ne crois pas d'avoir mieux l'expliquer.


 >>  >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...
 
Encore du SDX 3, non?


Rasik