Re: [sdx-developers] LuceneDocumentBase

[Pierrick Brihaye]

Salut,

Je reviens sur un point qui me paraît important...

Pierrick Brihaye a écrit:

> 2) la gestion des repository et des connections qui, à mon avis, devrait
> être sous la responsabilité des classes appelantes

Pourquoi ne l'ai-je pas fait alors qu'il suffisait de faire un 
couper/coller sur :
1) le code d'attribution de la connection
2) le code de fin de connection (clauses finally)

?

Pour une raison simple : en l'état actuel des choses, SDX postule que 
documents et documents attachés se trouvent dans le *même* repository. 
Cette approche me gêne car :

1) si on met du XML dans une BD, il est plus difficile d'y mettre des 
images, voire carrément impossible si on utilise des BD XML (en l'état 
actuel de leurs fonctionnalités).
2) mes images on vocation à être centralisées, pas mes documents. c'est 
bizarre, mais c'est comme ça.
3) SDX doit être générique et répondre aux besoins des utilisateurs, 
mêmes les besoins les plus farfelus. Sur ce point, vous pouvez compter 
sur moi :-)

Il me semble donc très souhaitable que l'on *puisse* balancer les 
documents attachés dans un autre repository que celui où se trouvent les 
documents (mais par défaut, on peut postuler qu'on les met dans le même 
repository). On n'aurait donc pas *une* connection, mais plusieurs. Et 
là, pour que ça soit performant, il faudrait utiliser un pool. Et, dans 
Cocoon 2, je ne sais pas (encore) faire :-)

Ces documents attachés posent également un autre problème : le lien est 
stocké dans l'entrée du/des document propriétaire dans le lookupIndex.

C'est là où ça va poser un problème : comment stocker N id, repository, 
(base de données), (application), (framework) dans un index Lucene qui 
ne suporte pas la hiérarchie comme je l'ai expliqué dans mes messages 
précédents ?

Deux solutions à vue de nez :

1) solution simple on utilise un truc du genre chemin inversé : 
attacheddocid/attachedocrepository[/attacheddocdb] etc...

2) on n'utilise plus le lookupIndex pour stocker les dépendances. A la 
place, on crée un *troisième* index (Lucene pour le moment). Dans cet 
index, on stocke :

doc1id, doc1repository, [doc1database], [doc1application], [doc1framework]

et

doc2id, doc2repository, [doc2database], [doc2application], [doc2framework]

Mieux, on ajoute un *type* de relation : pour les documents attachés, ça 
pourrait être "attacheddocument".

Et là, on rejoint une problématique évoquée par Martin : le découpage 
des gros documents en parties plus petites. Il suffirait dans ce cas 
d'utiliser un type de relation "ispartof" ou similaire...

Je tiens à préciser que cette approche qui vise a déporter les relations 
vers un index dédié ainsi qu'à typer ces relations semble avoir fait ses 
preuves au MCC dans une application réalisé pour l'Inventaire ;-)). Le 
fait que cette application tourne sous Access ne remet pas le concept en 
cause IMHO.

A bientôt,

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