Schéma pour une relation réflexive n-n

Bonjour à tous,

Soit un objet Catégorie, qui peut avoir 0-n catégories enfant, et 0-n catégories parent. J'ai tenté dans un premier temps de déclarer cette relation en utilisant refClass. Ce qui donne, en simplifié :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Category: columns: name: { type: string(45) } relations: Children: refClass: CategoryHasCategory foreign_id: parent_id Parents: refClass: CategoryHasCategory foreign_id: child_id   CategoryHasCategory: columns: parent_id: { type: integer, primary: true } child_id: { type: integer, primary: true } relations: ParentCategory: class: Category local: parent_id ChildCategory: class: Category local: child_id

---

Quand je génère le modèle à partir de là, je m'attends à voir dans la classe BaseCategory des accesseurs get/setChildren() et get/setParents(). Mais ce n'est pas le cas. En revanche j'ai bien un get/setCategoryHasCategory() n-aire.

Je peux sans doute me débrouiller avec ça pour faire mes formulaires d'administration (ou plutôt déclarer une relation n-n fictive sous forme de deux relations 1-n partant de latable d'association CategoryHasCategory.

Mais avant cela, je voudrais être sûr de ne rien rater. N'y a t'il pas moyen de déclarer ce genre de relations réflexives comme les autres relations n-n ?

Je pense que ton schéma pourrait être optimisé.

Mais avant de passer 20 minutes à y travailler, pourquoi n'utilises tu pas la notion doctrine de Hiérarchie, notamment la : Multiple Trees ?

Elle me semble plus adaptée pour ton cas.

Ha, voilà qui me semble intéressant. Merci pour l'info ! Je m'en vais éplucher cette doc de ce pas :D

Sinon, par pure curiosité, je me demande comment tu optimiserais ce schéma ? Si tu as du temps à perdre, je suis aussi preneur de ces informations là - c'est le genre de détails qui peut faire progresser dans la compréhension des mécanismes, parfois.

En fait, ce que je t'ai envoyé hier soir ne fonctionnera pas, par le fait que tu souhaite la possibilité d'avoir plusieurs parents... C'est sur que le système n'a pas été conçu pour gérer des orgies de catégories :mrgreen:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Category: columns: name: { type: string(45) } relations: Childrens: refClass: CategoryChild class: Category foreignAlias: Parents   CategoryChild: columns: parent_id: { type: integer, primary: true } child_id: { type: integer, primary: true } relations: ParentCategory: class: Category local: parent_id foreign: id foreignAlias: childs ChildCategory: class: Category local: child_id foreign: id foreignAlias: parents

---

Pas testé, mais a mon avis, cela devrait marcher.

En fait, il n'y a qu'une définition de refclass qui attaque deux fois la table elle même, et devrait générer deux méthodes sur la table category : ->getChildrens() et ->getParents()

A tester et vérifier et valider ...

[edit: premier paragraphe viré ^^]

J'ai examiné les NestedSets de Doctrine. Très intéressant en théorie et je pense que je pourrais simuler mon réseau avec des "multiple trees" en ajoutant une table, avec quelque chose sur le modèle :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Category: actAs: NestedSet: hasManyRoots: true rootColumnName: root_id columns: name: type: string(45) notnull: true   CategoryOtherTree: actAs: NestedSet: hasManyRoots: true rootColumnName: root_id columns: category_id: integer relations: Category: foreignAlias: OtherTrees

---

Cela permettrait de récupérer les comportements de NestedSet et les plugins qui vont avec pour les widgets et les validateurs. Cela m'éviterait d'avoir à gérer moi-même le calcul des 'level', je pourrais utiliser sfDoctrineTreePlugin, voire rendre optionnelle la vue en réseau et proposer une vue en arbre par défaut - il suffirait d'activer ou de désactiver la table annexe pour basculer d'un modèle à l'autre.

(nb : en fait, je pense que cette idée de relations n-n pour les catégories, au lieu d'un 1-n classique - est discutable et ne servira pratiquement jamais sauf pour nous compliquer l'existence, le code et la maintenance, mais pas moyen de convaincre le décisionnaire :roll:).

Bref, l'idée du NestedSet est tout de même intéressante mais pour le moment, je n'arrive pas à faire marcher ça. Je soupçonne des erreurs dans la façon dont j'ai rédigé mes fixtures.yml. Enquête en cours... 8-)