Discussion :

[Nanocom]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[Michel Rotta]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Nanocom]

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 ?

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

=> Ok.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é...)

[Michel Rotta]

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.

[Nanocom]

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 ?

[Michel Rotta]

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.