Re: [sdx-developers] Derniers commits

[Pierrick Brihaye]

Salut,

>Après avoir corrigé quelques petites bogues,

Oui, j'ai vu. Il faut que je contninue l'analyse de l'analyse ;-)

> j'ai ajouté du code de gestion des connexions

Vu aussi. J'ai encore quelques questions à ce sujet : je vais essayer de les
formaliser vite.

> Il reste les travaux à faire, mais maintentant, on peut
>améliorer ce code ensemble.

C'était l'objectif :-)

Maintenant qu'on sait de quoi on parle, quelques questions :

1) J'ai vu que Document comportait désormais une méthode getRepository(). Ca
va nous être utile... Cependant à partir de quand cette information est
disponible ? J'ai des NPE (attrapées) lors de la création de relations... Ca
n'est pas bloquant dans la mesure où les relations ne sont pas encore
réellement utilisées mais ça me tracasse.

2) A propos des relations, j'avais parlé du problème du sens de celles-ci.
Vu avez dû voir le code qui se propose de gérer les relations
bidirectionnelles. Quelques commentaires à ce sujet :

a) des relations bidirectionnelles, on n'en a pas (encore)
b) plutôt que d'ajouter du code là-dessus, code qui sera fastidieux à écrire
et qui grèverait la performance, je propose que, si un jour on a des
relations bidirectionnelles, on crée 2 relations : l'une dans un sens,
l'autre dans l'autre (c'est à dire qu'en l'état actuel des choses, les
relations se font toujours de A vers B). C'est ainsi que j'ai fait dans
Renabl. Je propose donc que le code que vous avez vu ne soit à considérer
que comme une "proof of concept".

3) Que pensez vous de ma proposition d'externaliser les lookups dans des
classes dédiées ? Ca permettrait de :

a) proposer d'autres architectures comme on l'a dans les Repository
b) confier certains processus à ces classes comme la gestion des batches
(j'y reviens de suite)

Je dois avouer que je n'ai pas encore beaucoup refléchi à ça. Que priviléger
? L'architecture (LuceneLookUp) ou les fonctionnalités (RelationLookUp) ? Et
pendant que je suis dans les lookups, n'oublions pas qu'on a aussi des
lookups de repository (FileSystem, URL) : il serait peut être pas mal
d'unifier un peu tout ça.

4) En ce qui concerne les batches, je crois qu'on a un choix stratégique à
faire. Pour moi, si un développeur d'applis appelle Index(...) c'est qu'il
veut que tous les documents transmis soient traités en même temps puisqu'il
aura fait le filtrage en amont.

En revanche, il est effectivement intéressant que les lookups travaillent en
batch. Soit l'exemple suivant :

une appli indexe 2 documents avec 10.000 documents attachés dans un
FSRepository. Dans l'état actuel des choses, le bacth ne sera appelée qu'une
fois : à la fin !

Or, on va avoir :

2 entrées dans l'index de recherche
2 + 10.000 = 10.002 entrées dans le lookup de la base
2 + 10.000 = 10.002 entrées dans le lookup du repository
10.000 entrées dans le lookup de relations
et, éventuellement, 2 documents originaux auxquels on doit adjoindre 2
entrées dans le lookup de repository

c'est donc seulement à ce moment que tout cela sera optimisé. Wow !

Si, en revanche, nous avions des classes de lookups, avec une interface
"Batchable" ayant des méthodes, setBacthCount(), setAutoBatch(),
forceBatchEnd() ou similaire, ces lookups seraient capables de lancer à
intervalles réguliers les optimisations requises.

Je signale aussi au passage, que le tout nouveau LuceneRepository
(excellente idée !) pourrait lui aussi bénéficier de cette interface.

Voilà. J'aurai d'autres questions, de détail cette fois, mais chaque chose
en son temps :-)

PS : pour l'appli d'administration, est-il possible d'avoir un peu plus de
place dans le form pour la locale ?

A bientôt.

p.b.