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@codelutin.com http://www.codelutin.com