[sf 1.4.x] Relation n:m avec l'admin generator

Bonjour,

J'essaie depuis 2 jours de faire fonctionner correctement une relation n:m avec l'admin generator de symfony 1.4, mais quelle que soit la configuration que j'essaie dans le schema.yml, j'obtiens toujours une erreur.

J'ai donc 3 tables (2 tables pour les données et une table de jointure entre les 2) et dans le formulaire d'édition pour ma première table, je voudrais avoir des cases à cocher qui s'affichent pour chaque possibilité (plutôt qu'une double liste à choix multiple ou une simple liste à choix multiple).

Voici le schéma que j'ai actuellement et l'erreur qui est retournée :

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

PdtArticle: connection: doctrine tableName: pdt_article columns: id: type: integer(4) fixed: false unsigned: false primary: true autoincrement: true code_fra: type: string(15) fixed: false unsigned: false primary: false notnull: false autoincrement: false code_ean: type: string(13) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: pourqui: class: PdtPourQui local: id_article foreign: id_pour_qui refClass: PdtArticlePourQui foreignAlias: Articles PdtArticlePourQui: connection: doctrine tableName: pdt_article columns: id_article: type: integer(4) fixed: false unsigned: true primary: true id_pour_qui: type: integer(4) fixed: false unsigned: true primary: true relations: PdtArticle: local: id_article foreign: id PdtPourQui: local: id_pour_qui foreign: id PdtPourQui: connection: doctrine tableName: pdt_pour_qui columns: id: type: integer(4) fixed: false unsigned: true primary: true autoincrement: true libelle: type: string(255) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: articles: refClass: PdtArticlePourQui class: PdtArticle local: id_pour_qui foreign: id_article foreignAlias: Pourqui

---

Et l'erreur qui est retournée :

Code:

---

1 2	500 | Internal Server Error | Doctrine_Exception Couldn't find class r

---

Dans la stacktrace, voici le DQL généré :

at Doctrine_Query_Abstract->_processDqlQueryPart('from', array('PdtArticle a', 'LEFT JOIN a.PdtTheme t', 'LEFT JOIN a.PdtTranchePrix tp', 'LEFT JOIN t.PdtUnivers u', 'LEFT JOIN r.PdtArticlePourQui PdtArticlePourQui'))

Apparemment, l'admin generator ne traduit pas ma relation par une requête correcte mais je ne parviens pas à trouver la configuration correcte.

Quelqu'un aurait-il une idée ?

Le problème ne provient pas du générateur d'administration mais du build de la base, a priori.

J'ai fais quelques essais et j'arrive à un schéma simplifié, peut-être un peu trop.

Code:

---

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

Article: columns: code_fra: { type: string(15) } code_ean: { type: string(13) }   Qui: columns: libelle: { type: string(255) }   Groupe: columns: article_id: type: integer(8) primary: true qui_id: type: integer(8) primary: true relations: Article: foreignAlias: Quis Qui: foreignAlias: Articles

---

• l'"Id" est automatiquement généré par doctrine si la table ne comporte pas de clef primaire
• La majorité des paramètres on des valeurs par défaut, il n'est donc pas nécessaire de les renseigner et le code en est plus lisible.
• Les relations ne nécessite l'écriture que d'un côté de la table (en principe)
• J'ai supprimé les nom de table en camel code, pour les tests, c'est peu lisible, après il sera toujours temps de les rajouter;

J'ai aussi monté un fichier de fixatures

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

Article: art1: code_fra: FR12345_1 code_ean: EAN12345_1 art2: code_fra: FR12345_2 code_ean: EAN12345_2 art3: code_fra: FR12345_3 code_ean: EAN12345_3 art4: code_fra: FR12345_4 code_ean: EAN12345_4   Qui: lib1: libelle: azerty_1 lib2: libelle: azerty_2 lib3: libelle: azerty_3   Groupe: grp1: article_id: art1 qui_id: lib1 grp2: article_id: art1 qui_id: lib2 grp3: article_id: art2 qui_id: lib2 grp4: article_id: art3 qui_id: lib3 grp5: article_id: art3 qui_id: lib1 grp6: article_id: art3 qui_id: lib2

---

Mais il ne passe pas sur l'ajout dans la table "Groupe".

Le sujet m'intéresse, je continue a explorer, si quelqu'un a une idée...

C'est bien ce que je craignais, pour les relations n:n il faut un peu plus de choses dans les relations qu'un simple 1:1 ou 1:n

Le schéma de la table qui fonctionne.

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 26 27 28 29 30 31

Article: columns: code_fra: { type: string(15) } code_ean: { type: string(13) } attributes: export: all validate: true   Qui: columns: libelle: { type: string(255) } relations: Articles: foreignAlias: Quis class: Article refClass: Groupe   Groupe: columns: article_id: type: integer(8) primary: true qui_id: type: integer(8) primary: true relations: Article: foreignAlias: Groupes Qui: foreignAlias: Groupes

---

• Il faut un bout de relation sur une des deux tables liées et des attributs pour l'autre.
• J'ai lu un truc quelque part il y a quelques jours sur le site de symfony pour indiquer dans le schéma de ne pas générer de groupeForm et de groupeFilter qui ne seront jamais utilisé et économiser un peu de lourdeur. Impossible de retrouver, mais je n'ai pas non plus vraiment chercher.

Les "fixtures" pour pouvoir tester

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

Qui: lib1: libelle: azerty_1 lib2: libelle: azerty_2 lib3: libelle: azerty_3   Article: art1: code_fra: FR12345_1 code_ean: EAN12345_1 Quis: [ lib1, lib3 ] art2: code_fra: FR12345_2 code_ean: EAN12345_2 Quis: [lib2, lib3 ] art3: code_fra: FR12345_3 code_ean: EAN12345_3 Quis: [ lib3 ] art4: code_fra: FR12345_4 code_ean: EAN12345_4

---

Pour faire joli on va aussi modifier la classe qui pour qu'elle retourne le libellé dans les listes

Code:

---

1 2 3 4 5 6 7 8

class Qui extends BaseQui { public function __toString() { return $this->getLibelle(); } }

---

et la classe article pour le fra

Code:

---

1 2 3 4 5 6 7 8

class Article extends BaseArticle { public function __toString() { return $this->getCodeFra() ; } }

---

Merci pour la réponse mimi68. Je vais tester ça.

Dans les relations que tu déclares dans Groupe, tu es bien sûr que symfony fait bien le lien automatiquement entre la colonne 'article_id' et la table Article et entre 'qui_id' et la table 'Qui' ?

Dans mes test oui.

Il crée dans l'objet BaseQui une méthode getArticles() qui retourne la collection des articles liés.

Idem dans BaseArticle avec getQuis().

C'est pas beau symfony ? Sauf qu'ici c'est surtout doctrine.
:ccool:

Merci pour ton aide mimi68!

La relation a bien fonctionné en remplissant le schema.yml comme tu l'as fait :ccool:

Effectivement le couple Doctrine/Symfony fait bien son boulot. Par contre, étant débutant sur symfony, je trouve le "diagnostiquage" d'erreur parfois un peu ardu. J'avais essayé des configuration très ressemblantes à celle que tu m'a donné mais qui n'ont pas fonctionné...

Effectivement, à ce niveau, quant cela ne génère pas correctement les tables avec "symfony doctrine:build", les messages d'erreurs sont plutôt légers.

Ma méthode consiste a créer un autre projet, vide, a faire mes test en dehors du gros projet de travail, puis, une fois le problème bien cerné, à le réintégrer dans le gros projet. J'ai donc toujours quelques répertoires testx près a accueillir mes essais.

Encore une chose, les lignes :

Code:

---

1 2 3 4

attributes: export: all validate: true

---

dans le modèle que j'ai donné ne semblent avoir aucun effet sur la relation n2n et peuvent donc être supprimées, sauf si elle sont nécessaire par ailleur.

Amicalement,
Michel

Merci pour l'info, je me posais la question pour ces 2 lignes effectivement.

Par ailleurs, je me posais aussi quelques questions sur les bonnes pratiques à adopter avec symfony concernant les modifications à effectuer sur le schema / la bdd, lorsqu'on travaille avec un environnement de production dont le serveur ne peut pas être coupé, et dont la base contient des quantités importantes de données.

Faut-il faire à chaque fois les modifications en parallèle dans le schéma et dans la base, ou bien uniquement dans la base et re-générer le schéma et les classes à chaque fois ? Tu aurais peut-être quelques conseils ou un lien intéressant à m'indiquer à ce sujet là ?

Merci encore pour le coup de main.

Nicolas

On sort du cadre d'un simple test de la relation n2n pour entrer de plein pied dans les stratégies de cycles de développements en entreprises.

Tu devrais avoir 2 serveurs (au minimum) et 4 environnement (au minimum aussi) sous symfony. Sans compter un système de gestion de version.

Environnement : développement
Sur un serveur développement, les bases de données aussi pour évité tous risque d'intervention sur l'environnement de production accidentel.
Il est destiné au développement. Les bases et les données doivent pouvoir être régénérées régulièrement (fixatures) pour que les tests du développeur puissent refaire régulièrement leurs tests.
Si la structure des données (le schéma) doit être modifié, on va le tester ici.

Environnement : test
Sur un serveur développement, les bases de données aussi...
Il est destiné aux tests automatique. Symfony embarque deux outils de test et il faut les utiliser en développant pour s'assurer qu'il n'y a pas de régressions lors du développement.

Environnement : Évaluation
Sur un serveur développement et/ou sur le serveur de production.
Il est destiné aux tests applicatifs réalisés par les utilisateurs ou par des testeurs non développeurs.
Les données sont en sous-ensemble des données de productions, ou des données adaptés, mais plus élaborées, généralement, que celle des deux environnement précédant.
La base de donnée n'est jamais régénérée par un build.

Environnement : Production
Sur le serveur de production.
Le plus sensible, il est destiné aux clients...
La base de donnée n'est jamais régénérée par un build.


Mais alors, comment va-t-on mettre a jour les évolutions de la base de données entre les versions dev et test et les deux autres ?

Une fois qu'une évolution de la base de donnée a été mise en place et testée, on va écrire des procédures doctrine de migrations. Qui peuvent être soit écrite à la main, soit être générées par doctrine et qui permettent surtout de ne pas écraser toutes la base de données et de tout perdre. Plus d'informations ici (en anglais).. C'est une fonctionnalité que je n'ai pas encore testé à fond.

Ok, merci pour toutes ces explications. Je vais me renseigner sur tout ça.