Salut,
Pour faire suite au échange précédent sur l'indexation des arbres. Et
les solutions actuelles qui sont au nombre de deux (que sur les
attachments, que sur les TreeNode). Voici après de grande réflexion le
résultat :)
En fait la bonne façon de faire, est d'utiliser les deux méthodes
d'indexation :).
- celle qui est utilisée actuellement qui sur chaque objet (attachment)
d'un Node ajoute de l'info
- celle qui ajoute de l'info sur les TreeNode eux même
L'implantation actuelle n'est vraiment pas performante en nombre de
requête SolR. Si on a un arbre de N noeud avec M attachment sur chaque
et qu'on les réenregistres, alors on fait N x M requête :( (j'exagère
un peu, mais pas beaucoup, car dans le pire des cas ca peu arriver :()
La nouvelle implantation (en cours) ne fait que 4 requêtes au pire quoi
qu'il arrive.
De plus dans l'ancienne version sur les grands arbres (N node), on se
retrouvait avec N nouveaux champs pour un attachment au niveau N. Dans
le nouveau, on a seulement 1 champs quoi qu'il arrive par noeud sur
lequel il est attaché (#attached.<treenodeid>). Il me semble qu'avec
l'ancienne, il se pouvait aussi qu'il y ait des problèmes pour mettre
le même attachment dans deux noeuds de la même branche d'un même arbre,
ici il n'y aura plus de problème.
Pour l'indexation des TreeNode on ajoute 3 champs, quoi qu'il arrive
(#root, #parents, #depth)
De cette façon, toutes les recherches sont rapides:
- facette (count du nombre d'attachment)
- recuperation d'un sous arbre jusqu'a une certaine profondeur
Dès que j'ai fini l'implantation je commit, et j'écris une doc qui
explique tout bien pour chaque cas et ce qui se passe pour l'indexation
(ajout d'un node/attachment, suppression d'un node/attachment) et tout
ce que ca implique.
--
Benjamin POUSSIN
--------------------
tél: +33 (0) 2 40 50 29 28
email: poussin(a)codelutin.com
http://www.codelutin.com
