Re: [sdx-developers] Derniers commits

[Pierrick Brihaye]

Salut,

Je viens de voir le commit du vendredi soir et je comprends mieux de quoi il
en retourne.

>>Je craignais qu'il y ait un
>> index Lucene de plus, mais Razik m'a dit qu'au contraire, tout allait
>> désormais s'unifier en une base Lucene à chercher, et une autre pour la
>> gestion interne SDX (repo, attached...)

> Ben, en fait, il y a effectivement un index de plus :

>1) un index pour stocker les infos sur le document (je n'ose les
>appeller métadonnées ;-) : id, repository, type mime.
>
>2) un index pour stocker les relations qu'entretient tel document avec
>tel autre (attaché, original et, à terme, fragment). La séparation m'a
>semblé nécessaire : si on détache un document lors d'une réindexation,
>pourquoi détruire/recréer une entrée dans le premier index alors qu'il
>suffit d'en détruire une dans le second ?

Oups ! On n'a effectivement plus qu'un seul index : il est vrai que Lucene a
cet énorme avantage de pouvoir stocker des "documents" dont la structure
n'est pas figée : on peut donc stocker dans le *même* index des "documents"
de type lookup et des "documents" de type relation.

Sur le fond, pas de problème, même si dans l'absolu un index à fort taux de
variabilité est moins performant qu'un index à faible taux de variabilité,
tant au niveau de l'espace disque (compression moins efficace) qu'au niveau
de la performance (moins de chance d'avoir un hit dans le cache). Je concède
cependant que le gain en temps d'accès doit compenser une partie des
inconvénients.... surtout que la variabilité reste tout de même bien
faible... enfin... pour aujourd'hui.

Cependant un index Lucene est selon moi une architecture *très* particulière
et on aurait dû *en plus* pouvoir externaliser ces index dans un package
comme cela a été fait pour les repositories. Par exemple le LookupIndex
aurait pu très facilement devenir un :

CREATE TABLE lookup (
doc-id VARCHAR(255),
doc-repository VARCHAR(255),
doc-mime-type VARCHAR(50),
...
);

Et le RelationIndex un :

CREATE TABLE relations (
doc1-id VARCHAR(255),
doc1-repository VARCHAR(255),
doc2-id VARCHAR(255),
doc2-repository VARCHAR(255),
relation-type VARCHAR(50),
relation-order INTEGER
);

Si on fusionne les 2 en gardant l'architecture actuelle (basée sur des
couples Field/Property, variante SDX des couples field/value de Lucene), je
ne vois pas comment faire sauf à gérer une combinatoire qui nous dépasserait
rapidement.

Une solution aurait pu être de proposer un modèle XML pour les objets dont
SDX a besoin de faire persister, mais je vois ça comme une perspective à
long terme. Les fichiers de configuration sont en XML : pourquoi pas ne
suivre la logique ? Concrètement, on aurait pu transmette aux index un DOM
du genre :

<!DOCTYPE sdxdocument ...>
<sdxdocument id="xxx" repository="yyy"/>
  <mime-type>text/xml</mime-type>
  ...
</sdxdocument>

et

<!DOCTYPE sdxrelation ...>
<sdxrelation type="attached" order="1">
  <document1 id="xxx" repository="zzz"/>
  <document2 id="yyy" repository="zzz"/>
  ...
</sdxrelation>

... à charge pour chaque architecture d'index de sérialiser ça de la façon
la plus adéquate possible, ce qui pour du SQL se fera forcément dans des
tables différentes selon, par exemple, un switch sur le documentType ou
l'élément racine.

En fait, je ne vois *que* Lucene et une XMLDB pour gérer ça correctement
dans un *même* espace. Il me semble donc qu'on doive faire plus générique,
pas forcément tout de suite, j'en conviens, mais ça a comme corollaire de ne
pas trop factoriser, même quand l'envie est grande.

A l'opposé, je conçois aussi que Lucene puisse n'être que le seul moteur
pour les index système de SDX 2.x... A vous de voir.

Mon dernier argument sera que Lucene écrit directement sur le système de
fichiers local et que certains ISP peuvent ne pas aimer.

Je termine sur mon examen du commit :

méthode : deleteRelationsToMastersFromRelationsIndex()

if (relationToParent == null)
  sdxRelationsIndexDB.delete(relationToParent);

Comme ça, ça ne va pas le faire :-)

A bientôt,

p.b.