Backend - Ajout d'une action dans l'édition

Les tables de liaisons dans le cadre d'une liaison n-n sont des cas particulier.

On peut facilement avoir une double clef primaire, pour ces tables. La seul restriction est que cette table ne doit pas être en relation avec une autre table que les deux tables qu'elle lie... (faut peut-être lire la phrase deux fois, je ne suis pas sur d'être très clair). En gros, même si c'est théoriquement possible, on ne peut pas avoir une clef composée (ceci semblerait être en voie de résolution dans la version 2.0 de doctrine, sur le papier du moins).

Dans ton cas, il n'y a pas d'autre liaisons, donc, pas de problèmes en vue.


Les paramètres foreign... permettent de définir les propriétés pour les autres côté de la relation. Définir la liaison de chaque côté, c'est prendre le risque que doctrine interprète la liaison comme deux liaisons distinctes et se mélange les pinceaux. Pourquoi faire long et compliqué alors qu'on peut faire vite et bien . La gestion des foreingAlias me semble fondamentale pour bien définir les relations, ça présence, souhaitée par doctrine, est, chez moi, une obligation. (Et la double définition d'une liaison est une interdite).

Citation:

---

On peut facilement avoir une double clef primaire, pour ces tables. La seul restriction est que cette table ne doit pas être en relation avec une autre table que les deux tables qu'elle lie... (faut peut-être lire la phrase deux fois, je ne suis pas sur d'être très clair). En gros, même si c'est théoriquement possible, on ne peut pas avoir une clef composée (ceci semblerait être en voie de résolution dans la version 2.0 de doctrine, sur le papier du moins).

---

Oui je comprend très bien, j'avais justement ce problème. La table permettant la liaison N-M était relié à une table 1-N Du coup la table prennait la clé composé en clé étrangère primaire + date si j'aurais voulu faire cela proprement.

Pour régler le problème j'avais mis une seul clé primaire partout pour éviter les emmerdes.

Citation:

---

Les paramètres foreign... permettent de définir les propriétés pour les autres côté de la relation. Définir la liaison de chaque côté, c'est prendre le risque que doctrine interprète la liaison comme deux liaisons distinctes et se mélange les pinceaux. Pourquoi faire long et compliqué alors qu'on peut faire vite et bien . La gestion des foreingAlias me semble fondamentale pour bien définir les relations, ça présence, souhaitée par doctrine, est, chez moi, une obligation. (Et la double définition d'une liaison est une interdite).

---

Ok, je vais donc modifier mon schema.yml pour refaire cela proprement. Je ferais cela au calme afin de pas casser le code et me tromper dans le nom des foreignAlias. Mais du coup, pour les type: many / one .. ca marche quand même ?

Par défaut, doctrine reconnait les liaisons 1-n et il n'y a pas de paramètres à mettre, quelque soit le côté ou tu mettes le lien. En général, je le met sur le coté n de la relation, cela évite d'avoir a rajouter un "class" dans la définition du lien.

Pour les liaisons 1-1, il faudra le préciser par type.

Pour les liaisons n-n, dans le cadre d'une liaison sans arguments sur le lien, on peut mettre des liens particuliers sur chacune des tables n qui permettent de récupérer directement les enregistrements de l'autre table, mais ici, ce n'est pas jouable, à cause des arguments sur le lien. Peut-être en v2 de doctrine...