Discussion :

[Herode]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Michel Rotta]

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.

[Herode]

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

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.

[Michel Rotta]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ...

[Herode]

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ).

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...