Re: [sdx-developers] Derniers commits

[Pierrick Brihaye]

Salut,

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

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

Ci-joint, une proposition qui pourrait bien convenir à tout le monde :-)

J'ai créé un package fr.gouv.culture.sdx.lookup qui contient 3 inferfaces et
un lookup Lucene *polyvalent*, c.a.d. capable de gérer aussi bien les
lookups de documents que les lookups de relations et de s'optimiser tout
seul... si on le lui demande.

C'est encore très rudimentaire, et pas très en phase avec les standards de
programmaton Cocoon, mais ça tourne (sous sdxworld).

Le code de LuceneDocumentBase a été révu : il est plus proche de mon dernier
commit, mais j'ai essayé d'y inclure les ajouts de Rasik.

Je pense que le code chargé des ajouts/destructions de documents est de plus
en plus robuste, mais cette classe a, à mon avis, encore besoin d'être
consolidée car son code ne garantit pas encore un Document (associé à ses
dépendances) entièrement construit au moment où on en a besoin :-(

Ce devrait pourtant logiquement être le cas après le processus d'indexation.
Citons quelques exemples
- lorsqu'on arrive dans add, la méthode Document.getRepositoryForStorage()
renvoie null et est donc plus dangereuse qu'autre chose
- lorsqu'on arrive dans add, les id et preferredfilename devraient déjà
avoir été positionnés
- idem pour le choix des repositories. Ceci explique pourquoi j'ai laissé de
côté la problématique de relations entre documents stockés dans des
repositories différents. Le code est prêt néanmoins.
- idem pour savoir si on doit créer ou bien mettre à jour un document
attaché
- idem pour la delete privée qui, étant synchronisée, mange énormément de
ressources à cause de ces calculs qui, à mon avis, auraient pu être faits en
amont.

J'ajoute également qu'on risque d'avoir des problèmes sur les méthodes
renvoyant des valeurs par défaut. On croit avoir ça et on a autre chose. A
la limite, je préfère une exception.

Quelques points pour terminer :

- les batches ne sont pas branchés (ça serait à mettre dans les index() et
delete() publiques)
- j'ai choisi fr.gouv.culture.sdx.lookup plutôt que
fr.gouv.culture.sdx.documentbase.lookup car je compte également mettre les
lookup de repository là-dedans.
- voir le code de init (et mon commentaire) pour n'avoir qu'un seul index
(Lucene) au lieu de deux ;-)

Voilà. Bonne fin de WE.

p.b.

Propositions.zip
Description: Zip compressed data