Formulaire et pseudo relation n-n (n-1 + 1-n)

Bonjour,

Je suis un peu perdu avec un cas qui me semble assez classique. J'ai fais pas mal de recherches, mais ça ne m'aide pas trop.

Voici mon cas : une base pour enregistrer des événements indésirables. Pour simplifier, il y a 3 étapes dans un process et un événement indésirable peut survenir sur 1 ou plusieurs étapes.

Le schéma de la base :
http://www.outils-sante.com/images/base.png

Le schema.yml :

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

Etape: connection: doctrine tableName: etape columns: etp_id_pk: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false etp_nom: type: string(45) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: ListeEtape: local: etp_id_pk foreign: lep_etape type: many Evenement: connection: doctrine tableName: evenement columns: evt_evenement_id_pk: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false evt_victime: type: string(45) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: ListeEtape: local: evt_evenement_id_pk foreign: lep_evenement type: many ListeEtape: connection: doctrine tableName: liste_etape columns: lep_evenement: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false lep_etape: type: integer(4) fixed: false unsigned: false primary: true autoincrement: false lep_incriminee: type: integer(4) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: Etape: local: lep_etape foreign: etp_id_pk type: one Evenement: local: lep_evenement foreign: evt_evenement_id_pk type: one

---

Mon objectif est de pouvoir faire un CRUD sur les événements en déclarant les étapes.
J'ai généré un module evenement, je peux donc faire un CRUD tout simple pour les événements.

Maintenant, je veux que quand je crée un nouvel événement, je puisse déclarer les étapes incriminées.

Là les choses se gâtent.

Dans /lib/form/doctrine/base/BaseEvenementForm.class.php , j'ai tenté d'ajouter un formulaire :

Code:

---

1 2 3 4

public function setup() { ... $this->mergeForm(new ListeEtapeForm());

---

Comme ça, je peux ajouter 1 étape... mais il faudrait que je puisse afficher 3 étapes.

Est-ce que quelqu'un pourrait me donner quelques billes de méthodologie? Quelques mots clés pour des recherche aussi.

Merci

Doctrine et symfony considère qu'une liaison n-n n'a pas à proprement parlé de table intermédiaire. (MLD)

Mais sans cette table c'est irréalisable physiquement (MPD).

Donc il faut une table, mais cette table doit avoir un format très particulier, elle ne peut comporter que deux champs (les deux clefs) tous les deux clefs primaire et la liaison doit se faire de cette table vers les deux autres et d'une des deux autres tables normale vers l'autre avec le paramètre "refClass" qui indique la table de liaison.

Toutes autre configuration est vouée à l'échec.

Dans ton modèle tu ne définis pas une liaison n-n, mais deux liaison 1-N avec la table liste étapes comme table pivot.

Traite les ainsi et tout devrait marcher.

Je suis débutant aussi j'espère pouvoir t'aider,
pour afficher les enregistrements de la table Etape il faut que tu ajoute dans ton schema.yml un foreignAlias puis que tu fasse dans ton evenementForm.class.php

Code:

---

$this->embedRelation('ton_foreignAlias')

---

tout simplement

Le schéma ainsi défini ne correspond pas à une relation n-n.

Donc, soit on en fait une relation n-n en supprimant le champ excédentaire et en corrigeant les relations ; soit le champ supplémentaire est indispensable et on n'a pas de relation n-n mais deux relation 1-n et n-1.

Quant le shema sera juste, on pourra toujours essayer de trouver la manière d'afficher les enregistrements. Là, tu vas lui laisser l'espoir de pouvoir faire fonctionner un n-n qui n'en est pas un.

oui effectivement j'ai eu le même dilemme, il faut que tes relations soit adaptées comme symfony le souhaite sinon ça ne peut pas marcher.

Fondamentalement c'est doctrine qui serait a cheval sur les règles.

Mais il a parfaitement raison. La relation n-n ne peut s'entendre que dans un MLD. Au niveau physique elle doit être "aidée" par une table. Et cette table ne peut comporter que les deux clef en champs. Si non, la donnée complémentaire ne peux trouver place dans le MLD et il faut donc le reprendre.

j'ai fait comme tu me l'a expliqué mimi et ça fonctionne très bien.
Au faite en parlant de formulaire, la je souhaite ajouter le widget sfWidgetFormInputDelete.class.php mais je ne sais pas dans quel repertoire le mettre dans symfony/widget ça ne fonctionne pas :koi:

8O keksako que sfWidgetFormInputDelete ???

Si tu veux mettre un widget personnel dans un projet c'est dans lib/widget/ de ton application. Le répertoire widget doit être créé pour l'occasion.

oui c'est un widget personnel récupérer dans un petit tuto, en faite je souhaite supprimer des enregistrement de ma table jointe en n:n, à tu deja été confronté à ça? quelle solution à tu mis en place?
merci

Bonjour,

Merci pour vos éclairages. Effectivement, il ne s'agit pas d'une relation n-n à proprement parler, même s'il me semble que dans le cours de Cyril Gruau (règle 3 du III-C), il fait bien mention de relation n-n avec une donnée supplémentaire dans la table de liaison.

Enfin bref, vous avez sans doute compris mon problème.

Si je transforme ma relation en "vraie" n-n, je perds l'information "étape incriminée" ... ce que je ne veux pas.

J'aimerais donc plutôt garder mon modèle de données, et afficher deux formulaires en 1.

Si je suis la réponse de Symfony3000, ça commence à prendre la forme que je souhaite.

J'ai ajouté ça au BaseEvenementForm :

Code:

---

1 2	$this->embedRelation('ListeEtapes'); ...

---

Mais ça n'affiche que le titre "ListeEtape"

Comment faire pour aller plus loin?

Pour continuer, j'ai ajouté au BaseEvenementForm :

Code:

---

$this->embedForm('formulaire',new ListeEtapeForm());

---

Ce qui m'affiche une seule ligne correspondant "lep_incriminee".

J'ai renseigné le champ pour voir et là il me renvoi une erreur :

Code:

---

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`test`.`liste_etape`, CONSTRAINT `lep_etape` FOREIGN KEY (`lep_etape`) REFERENCES `etape` (`etp_id_pk`) ON DELETE NO ACTION ON UPDATE NO ACTION)

---

.. je ne suis pas sûr d'être en bonne voie

Effectivement, certaine visions du MLD autorise des attributs dans le lien n-n.

Mais doctrine a été écris par des puristes...

Donc il faut considérer ta liaison comme deux liaisons 1-n. Après, c'est une question d'affichage.

ATTENTION !

Tu modifies le ficher BaseEvenementForm qui doit se trouver dans le dossier lib/form/doctrine/base.

Il ne faut jamais modifier les fichiers base<quelquechose>, ces fichiers sont régénère a chaque build de la base et sont effacé par symfony sans aucun préavis. Toutes les modifications apportés sont bien sur perdues... :cry:

Les modifications doivent se faire dans le fichier : lib/form/doctrine/EvenementForm/class.php qui, lui, n'est généré qu'une fois et n'est plus jamais modifié par symfony.

Une exception, le fichier : lib/form/BaseForm.class.php qui est le parent de tous les fichiers base<quelquechoses> et permet donc d'appliquer une méthode sur tous les fichiers form doctrine.

En quoi des attributs dans une relation n-n n'est pas "puriste" ? c'est pas autorisé ? J'ai toujours appris que c'était possible...

Hou, c'est vieux tous cela (pour moi...)

Dans certaines écoles qui tourne autour de l'analyse conceptuel et de Merise, les relations N-N ne devait pas exister et n'étaient vue que comme deux relation 1-N. La seul exceptions étant quant justement, il n'y avait aucun paramètre à prendre en compte. Je me rappel d'un prof qui passait son temps a démonter les relations n-n en trouvant LE paramètre qui foutait tous en l'air. Évidement, même 35 ans après, ça marque.

Ceci dit, et matériellement parlant (MPD) une relation N-N avec des attributs est équivalente à deux relation 1-N et trois tables.

Et au niveau du codage interne à doctrine (doctrine many to many), je pense qu'il était plus simple de coder des relation N-N stables et simple, donc sans attributs et de laisser les autres à la combinaisons de deux relations 1-N.

A partir de là, et sauf à aller regarder ce que pourrait faire propel (pas mieux dans mes vieux souvenirs), on n'a pas trop le choix. Que les attributs soient autorisés où pas dans le MLD, dans le MPD géré par doctrine, une table N-N avec attributs = 3 tables en 1-N et N-1.

Effectivement ... En fait j'ai choisi ce modèle de données parce qu'il est plus souple si on veut ajouter une etape possible. J'aurais pu tout mettre dans une table avec les colonnes victime/decollage/vol/atterrissage , mais c'est plus simple, selon moi de faire comme j'ai montré.
Ainsi, si j'ajoute une étape "approche", je dois juste ajouter un élément à la table "etapes" .. ce qui est mieux que d'ajouter une colonne à "evenements" (dites-le moi si je me prends le chou pour rien).

Sinon, pour mon problème, j'avance pas vraiment.

Comment je fais pour ajouter dans mon formulaire "evenement" les éléments de la table "etapes"?
Ces éléments doivent ensuite alimenter la table "liste_etapes".

Any who?

je vais chercher un peu avec ça :http://www.developpez.net/forums/d91...-many-to-many/

En fait, et en comprenant un peu mieux ton MLD, je pense que "... me prends le chou pour rien"

Si j'ai bien compris, tu parts sur le principe qu'une victime pourra être victime plusieurs fois ? 8O

J'ai toujours considéré qu'il y avait plusieurs étapes nécessaire dans le développement d'une application. La première est la structure des données que l'on veut gérer, une des suivante est la création des "personas" qui vont évoluer sur le site et ce qu'ils y feront, une des dernière est la création des écrans.

Si je peux me permettre un conseil, commence par le début, la fin viendra toute seul. :ccool:

une autre petite question, dans le même thème les relations n:n,
j'ai fait comme tu as expliqué mimi68, maintenant je souhaite supprimé des enregistrement de ma table joint
comment puis je proceder car j'ai un table de jointure avec les id des deux autre tables.
Dans une relation standard je fait comme ça mais la je ne peut pas a cause des clef étrangère

Code:

---

1 2	$ma_nomenclature= Doctrine::getTable('nomenclature')->find(2); $ma_nomenclature->delete();

---

Pas tout à fait mimi68.
Mon modèle est censé rendre plus facile l'ajout d'un paramètre.

Dans mon exemple, je décris des événements qui arrivent à une victime lors d'un processus qui comporte plusieurs étapes.

Je souhaite décrire quelles étapes du processus sont incriminées dans l'événement.

Aujourd'hui, mes étapes sont au nombre de 3 : décollage, vol, atterrissage.

Je pourrais tout à fait tout mettre dans une table avec les colonnes suivantes :

• id
• victime
• decollage_incriminé
• vol_incriminé
• atterissage_incriminé

Mais si demain mon client me demande d'ajouter une étape "roulage" par exemple, il faudrait ajouter une colonne à ma table. Or j'ai lu que cette situation n'est pas une bonne pratique.

C'est pour ça que j'ai voulu séparer deux tables : les événements et les étapes incriminées. Or cette structure nécessite une table intermédiaire...

@symfony30000
Je n'ai jamais :oops: testé les suppressions en n-n. Je pense qu'avec une bonne gestion des ondelete et quelques essais, on devrait y arriver. Ce qui doit être supprimé c'est l'enregistrement d'un des côtés et tous les liens dans la table de liaison. A tester.
Je te propose d'ouvrir un sujet différent de celui-ci pour ce problème, pour ne pas parasiter cette discussion et la rendre illisible.


@Vince57

OK, je comprend mieux la nécessité de la liaison n-n.

Sur un même incident, le client peut avoir eu des problèmes lors d'une ou plusieurs phases du vol.

Donc tu as une table vol (avions, numéro du vol,...), une table victime (nom, prénom,...), une table type d'incident. La table victime est en liaison 1-n avec la table vol (une victime appartient à un vol, mais un vol peut avoir plusieurs victimes) et la table victime est en liaison n-n avec la table type d'incident (une victime peut avoir un ou plusieurs type d'incident, mais un incident peut être arrivé à une ou plusieurs victime).

Par contre, je ne vois pas la pertinence de l'attribut "lep_incriminee" sur la liaison. J'ai deux manières de la comprendre, la victime est-elle incriminée dans un incident, dans ce cas la liaison devrait suffire. Ou alors, la victime pourrait être impliquée dans le déclenchement de l'incident mais elle pourrait, pour un même vol, être impliquée dans le déclenchement de l'incident en vol, mais pas à l'atterrissage.

Maintenant, imaginons qu'il y ait eu deux incidents sur le vol, un au décollage et un à l'atterrissage, deux incidents sans aucuns liens entre eux avec des victimes différentes et quelques victimes communes. Comment gères-tu cela ?

Ne pourrait-on pas avoir une structure : vol (les informations sur le vols) -> 1-N <- Incidents (description du problème) -> 1-N <- Impliqué (la victime et sa responsabilité) -> N-1 <- Victime (les références de la victime).