[sdx-developers] LuceneDocumentBase et documents attachés

[Pierrick Brihaye]

Salut,

Je continue par un canal plus traditionnel notre "conversation CVS" avec 
Rasik :-)

L'un des trucs qui me chiffonne en ce moment est la gestion de l'ajout, 
de la mise à jour et de la destruction des documents et de leurs 
documents attachés dans la LuceneDocumentBase (à remplacer par 
xxxDocumentBase).

Je souhaiterais, qu'on ai quelque chose de plus atomique de façon à :

1) intervenir sur le repository
2) intervenir sur le look-up index (j'aime bien ce terme... plus que 
"métadonnées système")
3) intervenir sur le search index

Tant que tout se passe normalement, pas de problème à vrai dire mais, en 
cas d'exception, une telle approche peut être grandement profitable car :

1) à partir d'un repository, on peut concevoir de reconstruire un 
look-up index
2) à partir d'un  repository et d'un look-up index, on peut concevoir de 
recréer un search index

... sans compter, et c'est peut-être le plus important, que l'on prépare 
l'indépendance d'architecture du look-up index promise par Martin ;-)

Selon moi, on devrait donc avoir une classe AttachedDocument avec une 
propriété WhatToDoWithMe :-) Cette propriété aurait comme valeurs 
possibles : PUT_ME_INTO_THE_REPOSITORY, DELETE_ME_FROM_THE_REPOSITORY, 
STILL_DONT_KNOW_WHAT_TO_DO_WITH_ME

Avant l'ajout ou la destruction d'un document, pas de problème : les 
documents attachés vont subir le sort de leur propriétaire.

Là où ça coince (un peu) plus, c'est lors de la mise à jour. En effet, 
il faut distinguer les documents attachés existant *avant* la mise à 
jour et ceux existant *après* la mise à jour et positionner la propriété 
en conséquence.

Une telle structure doit bien sûr être sérialisable/désérialisable sur 
le look-up index (Lucene pour l'instant).

Autre point là-dessus : il me semble avoir vu que les documents attachés 
devaient être dans le *même* repository que leur propriétaire. Ca me 
gêne un peu car on pourrait avoir le XML dans une XMLDB ou une SQLDB et 
les documents attachés dans un FSRepository ou un URLRepository. Bref, 
ce qui manquait à SDX 1.

Point connexe aux documents attachés : si l'on permet plusieurs 
indexations, ne vaudrait-il mieux pas disposer d'un pipeline spécifique 
pour déterminer la liste des documents attachés ? Par défaut, il 
pourrait être bâti sur la même architecture que le pipeline d'indexation...

Point connexe au point connexe : si l'on permet plusieurs indexations, 
ne vaudrait-il pas mieux disposer d'un pipeline spécifique pour 
déterminer l'id du document ? Par défaut, pourrait être bâti sur la même 
architecture que le pipeline d'indexation... :-)

Autre point : maintenant que j'ai fait la preuve que SDX1 peut être 
déployé sous Tomcat 4.x, ne vaudrait-il pas mieux tout remapper en sdx2 ?

A+

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