Problème avec mes FK

Hello,

Dans le cadre de mon entrainement à l'utilisation de symfony, j'ai commencer à mettre en place ma base de donnée dans le fichier schema.yml, voici son contenu :

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 78 79 80 81 82 83 84 85 86 87 88

Billets: actAs: Timestampable: ~ Sluggable: fields: [titre] columns: author: type: integer notnull: true category: type: integer notnull: true titre: type: string(45) notnull: true unique: true contenu: type: string() notnull: true visible: type: integer(1) default: '1' notnull: true relations: Utilisateurs: local: author foreign: id foreignAlias: BilletsAuteur Categories: local: category foreign: id foreignAlias: BilletsCategorie   Categories: actAs: Sluggable: fields: [nom] columns: nom: type: string(45) notnull: true unique: true   Commentaires: actAs: Timestampable: created: name: created_at type: timestamp format: Y-m-d H updated: disabled: true columns: billet: type: integer notnull: true pseudo: type: string(45) notnull: true email: type: string(45) notnull: true site: type: string(45) notnull: false contenu: type: string() notnull: true ip: type: string(45) notnull: true relations: Billets: local: billet foreign: id   Utilisateurs: columns: pseudo: type: string(45) notnull: true email: type: string(45) notnull: true passwd: type: string(45) notnull: true

---

un petit

Code:

---

1 2	symfony doctrine:build all

---

Puis mes tables se sont inséré en base sans problème.

J'ai ensuite voulu ajouter des fixtures, voici mes fichiers :

Code:

---

1 2 3 4 5 6

categories: malife: nom: Ma Life dev: nom: Programmation

---

Code:

---

1 2 3 4 5 6 7

utilisateurs: aosix: pseudo: AoSiX email: julien@ao6-labs.eu passwd: aosixpwd

---

Code:

---

1 2 3 4 5 6 7 8

billets: bienvenue: author: aosix category: malife titre: Bienvenue sur le blog ! contenu: je suis le contenu du blog visible: 1

---

Lorsque je fait un data-load, l'obtient une erreur ( c'est chez moi et du coup je me souviens plus exactement de l'erreur mais c'est... ) à propos de mes FK, comme quoi il y a un problème de contrainte.

y a t'il un problème dans un de ces fichiers ? Je vous avourez avoir fait mes Relations un peu au hasard car je ne suis pas sur d'avoir tout compris à leurs fonctionnement.

Tes clés étrangères sont en : type: integer.

Est-ce que cela correspond exactement au type utilisé pour les clés des tables User et Categories dans la base ?
Dans le doute, essaye de les déclarer en integer(11), vérifie s'il faut ou non les déclarer unsigned, etc.

Hello,

je viens de regarder en base, tous sont des BIGINT(20) signé ( les 'id' et les champs qui y font références ), aucune différence notable donc.

Tu devrais pas faire plutôt :

Code:

---

1 2 3 4 5 6 7 8

billets: bienvenue: Utilisateurs: aosix Categories: malife titre: Bienvenue sur le blog ! contenu: je suis le contenu du blog visible: 1

---

?

Comme le dit Tirkyth c'est le nom du lien utilisé dans relation qu'il faut utiliser dans fixture, et non le nom du champ de liaison.

Par contre, quelques remarques sur ton schéma.

Utilise, pour le nom du champ de liaison quelque chose du genre <nom>_id. Dans la table billet, le champs author devient alors author_id, plus lisible et conforme aux conventions doctrine.

Le nom des tables devraient toujours être au singulier, en effet, chaque enregistrement comporte un billet.

Dans les liaisons 1-N, le nom de la liaison unique ne devrait pas comporter de S, dans la table billet, l'auteur est unique, le S laisse supposer qu'il pourrait y avoir plusieurs auteurs... Par contre, du côté multiple, le S permet d'indiquer qu'il y a plusieurs billetS pour un auteur et donc, que l'on va récupérer une collection_doctrine.


Le schéma devient donc :

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 78 79 80 81 82 83 84 85 86 87 88 89

Billet: actAs: Timestampable: ~ Sluggable: fields: [titre] columns: author_id: type: integer notnull: true category_id: type: integer notnull: true titre: type: string(45) notnull: true unique: true contenu: type: string() notnull: true visible: type: boolean default: true notnull: true relations: utilisateur: local: author_id foreign: id foreignAlias: auteurs categorie: local: category_id foreign: id foreignAlias: categories   categorie: actAs: Sluggable: fields: [nom] columns: nom: type: string(45) notnull: true unique: true   commentaire: actAs: Timestampable: created: name: created_at type: timestamp format: Y-m-d H updated: disabled: true columns: billet_id: type: integer notnull: true pseudo: type: string(45) notnull: true email: type: string(45) notnull: true site: type: string(45) notnull: false contenu: type: string() notnull: true ip: type: string(45) notnull: true relations: billet: local: billet_id foreign: id foreignAlias: billets   Utilisateur: columns: pseudo: type: string(45) notnull: true email: type: string(45) notnull: true passwd: type: string(45) notnull: true

---

On a donc pour un billet récupéré dans $billet l'objet auteur $billet->getAuteur(), l'objet catégorie $billet->getCategorie() et la collection des objets commentaires avec $billet->getCommentaires()

De même depuis un commentaire dans $commentaire, on a le billet correspondant dans $commentaire->getBillet(), et le nom de l'auteur du billet commenté par $commentaire->getBillet()->getUtilisateur() encore mieux, les tous les comentaires du billet, dans une collection par $commentaire->getBillet()->getCommentaires()

De quoi envisager quelques perspectives intéressantes...

Bonjour mimi68,

Merci pour ces règles de nommages spécifique à doctrine, je ne les connaissait pas ( et ne comprend même pas l'intérêt du foreignAlias ) mais j'essaierai de m'en souvenir pour la suite !

Aussi, je me demandais si vos remarques concernent seulement les conventions de nommages ou apportent elles un changement vis à vis des liens possible dans les modèles (mis à part le nom des méthodes, cela va de soit ) ?

C'est surtout les conventions de nommage, mais elles aident à la compréhension d'un schéma.

Les relations sont définie sur une seul des deux tables. Mais elles doivent pouvoir donner des informations pour les deux côtés de la relation. Ce qui est préfixé par foreign ce trouve de l'autre côté de la relation.
[list][*]foreignId pour l'id de l'autre côté de la relation[*]foreignAlias pour l'alias de cette relation vue par l'autre table.[*]

Tout cela est très confu, je viens de jeter un oeil sur jobeet et je tombe sur

Code:

---

1 2 3 4 5 6 7

JobeetJob: #...... category_id: { type: integer, notnull: true } #...... relations: JobeetCategory: { onDelete: CASCADE, local: category_id, foreign: id, foreignAlias: JobeetJobs }

---

Dans cet exemple, le foreignAlias est JobeetJobs, ce qui me laisse présumer que $category->getJobeetJobs() marchera pour obtenir les jobs d'une catégories ( ai-je tord ? )

Bref, dans mon cas nous avons

Code:

---

1 2 3 4 5 6

relations: utilisateur: local: author_id foreign: id foreignAlias: auteurs

---

Par rapport à Jobeet, on est dans la logique inverse, est-ce une erreur ou y a t'il un sens à cela ?

Exemple Jobeet.

depuis un objet JobeetJob tu récupères la catégorie par :
$JobeetJob->getJobeetCategory() ---> un objet catégorie

depuis un objet JobeetCategory tu récupères la collection des job par :
$JobeetCategory->getJobeetJobs() ---> une collection d'objets job


Par contre, sauf erreur de ma part, on n'a la même logique dans ton schema.

Note que l'on pourrait parfaitement définir le lien depuis l'autre table de la liaison. On aurait alors sur la table utilisateur :

Code:

---

1 2 3 4 5 6 7

relations: auteurs: class: auteur local: id foreign: auteur_id foreignAlias: utilisateur

---

A noter le mot clef class qui permet de préciser que la class de liaison est auteur et non pas auteurs, c'est pour cela et pour simplifier que l'on défini en général depuis l'autre côté de la relation.

Bonsoir,

Je ne comprend sincèrement pas en quoi mon schema est différent de celui de Jobeet. On a un des catégories, puis des billets avec une relation vers la catégorie, exactement comme dans Jobeet non ? Mis à part que leurs billets s'appellent des "Job"

Il m'a fallu regarder le code source pour comprendre qu'une erreur est commise sur le nommage des foreignAlias.

J'ai trouvé :

Code:

---

1 2 3 4

$this->hasMany('Commentaire as billets', array( 'local' => 'id', 'foreign' => 'billet_id'));

---

Alors que si je met foreignAlias à commentaires, j'aurai sans doute Commentaire as commentaires non ?

Citation:

---

Envoyé par mimi68

Par contre, sauf erreur de ma part, on n'a la même logique dans ton schema.

---

Juste en rappel. Ce qui signifie que ton schéma est le même que celui de Jobeet. Ceci règle le premier message.

Maintenant, si dans ton schema tu mets :

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

Billet: actAs: Timestampable: ~ Sluggable: fields: [titre] columns: author_id: type: integer notnull: true category_id: type: integer notnull: true titre: type: string(45) notnull: true unique: true contenu: type: string() notnull: true visible: type: boolean default: true notnull: true relations: utilisateur: local: author_id foreign: id foreignAlias: titis categorie: local: category_id foreign: id foreignAlias: tutus ....

---

Dans l'objet $categorie tu accéderas a la collection des billets par $categorie->getTutus()

et si tu met dans ton schema

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

Billet: actAs: Timestampable: ~ Sluggable: fields: [titre] columns: author_id: type: integer notnull: true category_id: type: integer notnull: true titre: type: string(45) notnull: true unique: true contenu: type: string() notnull: true visible: type: boolean default: true notnull: true relations: toto: class: author local: author_id foreign: id foreignAlias: auteurs categorie: local: category_id foreign: id foreignAlias: categories ...

---

tu pourras accéder depuis un objet $billet à l'utilisateur auteur par $billet->getToto().

Remarque dans la relation toto le paramètre class qui permet d'associer une class (table) à une relation dont le nom serait différent du nom de la table.

Hello,

Donc pour en terminer, si je fait

Code:

---

1 2 3 4 5 6 7 8 9 10

relations: utilisateur: local: author_id foreign: id foreignAlias: billets categorie: local: category_id foreign: id foreignAlias: billets

---

Je pourrais donc lister mes billets depuis la catégorie choisie par $categorie->getBillets() ? Ce qui me semble plus logique que $categorie->getCategories() qui était convenu au départ.

Oui

Et c'est plus logique et plus lisible...



Il nous reste un problèmes pour ceux qui lirait ces lignes, c'est les noms de tables qui au singulier ce terminent par un s... (exemple : sas) là on a un problème, il faudrait utiliser un autre nom pour la table parce que "sass" perd beaucoup de son sens !

Et comme le français est une langue curieuse, il nous reste la table cheval ... qui partira en chevaux... et autres plaisirs de ce genres.

L'anglais n'est pas nécessairement mieux et réserve de surprises aussi.

Bonne chance.

Merci beaucoup pour tout ces éclaircissements, je peux enfin continuer sereinement !