Salut, En refactorant l'indexation pour comprendre comment tout ça fonctionnait, je me suis aperçu (à moins que je ne me trompe) que ce n'était pas vraiment optimal comme façon de faire. Concept ======= On a des TreeNode avec un 'parent' qui donne la structure de l'arbre. Chaque TreeNode peut avoir des attachments qui sont des objets attachés à un noeud. On veut pouvoir retourner le nombre d'attachments à partir d'un noeud qui satisfassent un critère (1 level ou tous les sous fils). Ce nombre d'attachments représente le nombre d'attachment du TreeNode demandé mais aussi tous ses fils. Actuellement ============ Lors du store d'un objet s'il fait parti des attachments d'un TreeNode on lui ajoute plusieurs champs - tree.parentId = childId (N fois pour representer tout le chemin juste qu'au root) (pour le TreeNode contenant cet attachment on met comme childId le marqueur 'empty') - tree.root= rootId Cela permet de faire des recherches sur les objets en facetisant facilement sur le fait qu'il soit dans un arbre ou non. Les problèmes sont: - on multiplie le nombre de champs de facon important dans solr (Si l'attachment est dans 3 arbres a une hauteur de 6 on crée ~18 nouveaux champs solr (je ne sais pas comment solr se comporte avec beaucoup de champs à indexer) - qu'il est coûteux de faire ainsi lorsque l'arbre a beaucoup d'attachment. Dès qu'on change un TreeNode, il faut ré-indexer tous les attachments de ce TreeNode mais aussi de ses enfants. (injouable par exemple sur jurismarches après quelques années d'utilisations avec plusieurs milliers d'attachments par noeud). Proposition =========== Ce que je propose est de modifier la façon d'indexer les arbres pour que ce soit les TreeNode eux même qui aient des informations complémentaires et non pas leurs attachments. On ajoute donc à chaque TreeNode: - tree.parents = liste de tous les parents (champs multi-value) - tree.root = rootId Un noeud et ces fils ne sont ré-indexés que si le champs 'TreeNode.parent' est marqué dirty ou qu'il est null (création d'un nouvel arbre) exemple: root->n1->n2->n3 root: * treenode.parent=null * #tree.root=rootid * #tree.parents=rootid n1: • treenode.parent=rootid • #tree.root=rootid • #tree.parents=n1id,rootid n2: • treenode.parent=n1id • #tree.root=rootid • #tree.parents=n2id,n1id,rootid n3: • treenode.parent=n2id • #tree.root=rootid • #tree.parent=n3id,n2id,n1id,rootid Ce que cela change ================== Cela ne permet plus de faire des recherches sur les attachment facetisé sur TreeNode, mais il y a peut-etre d'autre moyen de faire (actuellement cela ne semble pas utilisé) Ré-indexation ------------- Fréquence: dépend de l'application et de la fréquence de la modification des arbres (potentiellement élévé, ne doit pas être coûteuse) si field dirty contient 'parent' ou est null on reindex ce noeud et tous les noeuds trouvé par la requete query(tree.parents=nodeId) actuellement: N requêtes, N store. Avec N = nombre d'attachment nouveau: total 1 requêtes + M store. Avec M = nombre de noeud fils Recherche du nombre d'attachment pour un noeud et ses fils ---------------------------------------------------------- Fréquence: dépend de l'application, mais souvent élevé (affichage d'arbre avec le nombre entre parenthèse) si on souhaite connaitre le nombre d'attachment d'un noeud (avec les sous noeuds) on fait la recherche (tree.parents=nodeId) on boucle sur les resutats pour additionner les attachments de chaque noeud (total 1 requete) (actuellement 2 requetes) Recherche des attachments suivant un critère -------------------------------------------- Fréquence: dépend de l'application, mais normalement rare Si on souhaite recherche les attachment suivant un critère a partir d'un noeud, on fait la recherche (tree.parents=nodeId) on concatene tous les ids de tous les attachment des noeuds trouves. Puis on relance une recherche (critère demandé) où l'on a ajouté une condition pour que les documents retournés doivent être dans la liste des id des attachments précédemment construite. (total 2 requêtes) (acutellement 1) Question ======== - voyez vous des problèmes dans la nouvelle proposition - supprime-t-on l'ancien indexer par le nouveau ou laisse-t-on les deux a disposition ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii