Unknown record property lors d'un data-load

Bonjour, j'ai un problème avec sfGuardPlugin.
J'ai suivi la procédure pour lier la table sf_guard_user avec ma propre table membre, et voici mon 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

Profile: connection: doctrine columns: sf_guard_user_id: type: integer(4) fixed: false unsigned: true primary: true autoincrement: true date_naissance: type: date(25) fixed: false unsigned: false primary: false notnull: false autoincrement: false lieu: type: string(45) fixed: false unsigned: false primary: false notnull: false autoincrement: false created_at: type: date(25) fixed: false unsigned: false primary: false notnull: false autoincrement: false relations: User: class: sfGuardUser type: one

---

J'ai créé un user de base dans mon fixtures.yml :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

sfGuardUser: Arnaud: first_name: Arnaud last_name: Bidule email_address: test@free.fr username: Nanocom password: admin is_super_admin: true Groups: [Group_admin] Profile: lieu: Strasbourg

---

(Je ne vous l'ai pas mis en entier parce que l'erreur se passe ici).
Donc quand je fais un doctrine:data-load, on me répond : "Unknown record property / related component "0" on "Profile""

J'ajoute que j'ai suivi notamment ce billet de blog pour faire ça : http://symfony.com/blog/call-the-exp...ineguardplugin

Savez-vous résoudre mon problème ? Merci !

Ne jamais partir de la base pour générer le shema.yml, sauf s'il est réellement impossible de faire autrement.

Le schéma "à ma façon"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Profile: connection: doctrine columns: sf_guard_user_id: type: integer unsigned: true primary: true date_naissance: date lieu: string(45) relations: User: class: sfGuardUser local: sf_guard_user_id foreign: id foreignAlias: Profile type: one foreignType: one

---

Le created_at n'a pas d'intérêt, il est déjà géré dans la table sfGuard. S'il est indispensable il y a tout intérêt à utiliser le behavior de doctrine.

Il est souvent préférable d'étendre la classe sfGuardUser

Code:

---

1 2 3 4 5 6 7 8 9

Profile: connection: doctrine inheritance: extends: sfGuardUser type: simple columns: date_naissance: date lieu: string(45)

---

Ce qui évite d'avoir à gérer une double création et une relation pour des données qui, physiquement, ont tout intérêt à se positionner dans une seule table.

Citation:

---

Ne jamais partir de la base pour générer le shema.yml, sauf s'il est réellement impossible de faire autrement.

---

=> J'avais vu que c'était préférable d'écrire le schema.yml à la main, oui. Mais le problème c'est qu'après je peux pas gérer les types de MySQL comme je veux (faire un mediumint 6 par exemple), et de toute façon j'ai fait toute ma base de données sous workbench donc je trouvais ça logique de faire du forward engineering dessus puis de récupérer la base et générer le schema.yml. Qu'est-ce que t'en penses ?

Citation:

---

Le created_at n'a pas d'intérêt, il est déjà géré dans la table sfGuard.

---

=> Ok. :)

Citation:

---

Il est souvent préférable d'étendre la classe sfGuardUser

---

=> Ok, merci !

Edit : du coup, ça marche toujours pas, j'ai fait le schema que t'as mis, et j'ai fait un build --all et on me répond "Key column 'sf_guard_user_id' doesn't exist in table". Alors j'ai rajouté une colonne "sf_guard_user_id" pour voir, et j'ai une autre erreur : "Can't create table"... Je crois que le problème vient de l'inheritance : ne faut-il pas la mettre en "Concrete" ?

Bon, j'ai réussi au final : mon schema :

Code:

---

1 2 3 4 5 6 7 8

Profile: connection: doctrine inheritance: extends: sfGuardUser type: simple columns: date_naissance: date lieu: string(45)

---

(Celui que tu m'as donné)
Et mes fixtures :

Code:

---

1 2 3 4 5 6 7 8 9 10

sfGuardUser: Arnaud: first_name: Arnaud last_name: ferfefe email_address: feef@wfrferfe.fr username: Nanocom password: admin is_super_admin: true Groups: [Group_admin] lieu: Strasbourg

---

Voili voilou :) merci !!! (et ma première question est toujours d'actualité...)

Citation:

---

Qu'est-ce que t'en penses ?

---

Comme j'ai déjà dû l'écrire très souvent ici, le shema.yml n'est pas la description de la structure des données mais celle du modèle des données, modèle objet des données et ce n'est pas la même chose.

Avec symfony/doctrine nous attaquons un modèle objet qui représente des données. C'est ce modèle qui va les stocker sur le disque dur, la méthode et les moyens utilisés pour le stockage ne nous importent pas au premier niveau, ce qui nous intéresse c'est de retrouver le modèle objet et nos données. Sauf à traiter des volumes réellement énormes de données, le format de stockage n'as plus beaucoup d'importance de nos jours.

MySqlWorkbench est un bon outil qui permet de générer un bon MPD. Mais partir de la base ainsi générée va nous créer un modèle de données optimisé pour gérer une structure physique de données et pas les modèles objets dont nous avons besoins.

On peut cependant partir du schéma réalisé avec MySqlWorkbench dans certains cas (en effet, des outils tel que l'héritage de table n'y sont pas représentables) et générer un shema.yml de départ à l'aide de l'outil intégré d'exportation.

Dans tous les cas il conviendra de reprendre le shema.yml ainsi généré et de l'adapter à nos besoins, c'est à dire en faire un modèle objet viable.

Il ne faut pas oublier non plus qu'en utilisant symfony/doctrine nous utilisons une couche d'abstraction entre la base de données et notre application. Si nous partons correctement de notre shema.yml optimisé pour notre application, nous pourrons alors travailler avec une base sous MySql, serte, mais aussi une base SqLite ou Oracle ou MsSql ou Postrgree ou ... Chose qui ne sera peut-être pas aussi simple avec un modèle (shema.yml) trop ouvertement orienté vers une base de données précise.

A la question suivante, est-ce nécessaire d'envisager de changer de base ? La réponse est oui, j'ai une application qui tourne, suivant les sites sous MySql et SqLite. Et une autre en cours d'écriture qui devrait tourner sous MySql, MsSql et Oracle suivant les sites.

Ok, merci.
Mais on est donc d'accord sur le fait que lorsqu'on part du schema.yml pour créer nos tables, on ne peut pas modifier la table derrière (puisqu'elle sera réécrite à chaque modification) ?

Et sinon, à quand le tuto là-dessus ?

En effet, les tables sont une conséquence du shema.yml et non le contraire (en principe).

Il n'y a pas de tuto prévu la dessus, hélas.

Par pour la version 1 de symfony du moins.