[sf 1.4.x] Unknown record property "permissions" on "sfGuardUser"

[Colmea]

EDIT: Je viens de me rendre compte que le topic aurait été plus pertinent dans le sous-forum plugin, mille excuses :s

Bonjour à tous

Je me permets de poster un topic pour vous faire part de mon problème. Généralement j'arrive à m'en sortir, mais pas cette fois :/

Voici le shmilblik: J'ai téléchargé l'intégralité de mon projet Symfony depuis mon serveur dédié vers mon nouveau portable pour pouvoir y travailler en local.
J'en ai donc aussi profité pour importer la totalité de mes tables directement dans phpmyadmin par une requête sql.

Tout fonctionnait en local, jusqu'à ce que je décide de build le schema de ma bdd (précédemment importée dans phpmyadmin) avec un doctrine:build-schema puis de construire mes models avec un doctrine:build --model avec ce nouveau schéma.
En effet, maintenant dès que je me connecte sur mon site en local (dès que j'utilise sfGuardUser donc), voici l'erreur que j’obtiens:

"Unknown record property/related component "permissions" on "sfGuardUser"

Cela me semble étrange puisque les models ont été créés à partir du schéma qui lui-même provient de ma base de donnée qui fonctionnait très bien deux minutes auparavant (en local ET sur mon serveur de production).

Voici le schéma (une partie en tout cas) généré à partir de ma bdd:
http://pastebin.com/Kcvw46V9


Pour infos, non je n'ai plus le schema.yml sur mon serveur de production :/ Je ne sais pas pourquoi.
Version de Symfony : 1.4.4


Savez-vous d'où cela peut-il venir ?

Merci d'avance pour votre aide
Colmea

[Michel Rotta]

Savoir non, soupçons ? peut-être.

Je vais interviewer papy Mousot !

Question comment as-tu pu régénérer un schéma en local sans ton shema.yml ?

Est-ce toi qui à développé l'application originel ?

As tu récupéré symfony du serveur ? Et les plugins ?

Je vois deux pistes qui se dégagent :
- Version de sfGuard différente sur le serveur et sur ton poste
- Modification du modèle dans la base de données à la main après la génération

Mais aucune des deux n'explique l'ensemble des symptômes...

[Colmea]

Envoyé par Michel Rotta

Question comment as-tu pu régénérer un schéma en local sans ton shema.yml ?

Justement. Le schema.yml a été généré avec la commande doctrine:build-schema qui l'a buildé depuis ma base de donnée que je venais d'importer de mon serveur de production via phpmyadmin.

Envoyé par Michel Rotta

Est-ce toi qui à développé l'application originel ?

Oui. Malheureusement, mon ancien portable a grillé, je n'ai donc plus de version locale.

Envoyé par Michel Rotta

As tu récupéré symfony du serveur ? Et les plugins ?

Oui, tout a été récupéré du serveur en fait. J'ai bêtement copié l'intégralité du dossier vers mon portable, en changeant la configuration pour pouvoir accéder à ma bdd évidemment.

Envoyé par Michel Rotta

- Version de sfGuard différente sur le serveur et sur ton poste
- Modification du modèle dans la base de données à la main après la génération

Pour la version d'sfGuard, j'en doute puisque j'ai directement copié le dossier plugin vers mon portable.
Par contre non, je n'ai aps modifié ma bdd à la main après la génération du schema. Par contre, j'ai plusieurs fois modifié la bdd du serveur de production à la main pour y ajouter un champ et ainsi éviter de devoir refaire un build --all qui écraserait toutes mes donnée déjà accumulée dans la bdd (étant donné que mon projet tourne déjà et accueille des visiteurs).

Petite question, existe-t-il un schema par défaut pour le plugin sfGuard ? Celui-ci est-il pris en compte lors du build des model, ou seul mon schema.yml situé dans config/doctrine est pris en compte ?
Car a ce moment-là, il pourrait s'agir d'une "interférence" entre les deux schéma du plugin sfGuard (puisque le schema des bdd sfGuard a été généré dans mon schema.yml, comme vous l'avez vu).

Merci pour l'attention que vous portez à mon problème

Colmea.

[Michel Rotta]

Dur dur...

Ceci ne vas pas être des plus simple.

Avais-tu un shema.yml à l'origine ? Comment as-tu construit ta base ?

Je n'avais pas vus/compris que tu avais récupéré le shema depuis la base.

En effet, sfGuard à son propre schéma qui vient s'ajouter à celui que tu as fait pour ton application. Mais il ne le fait que si les tables ne font pas parties de ton shema.yml, hors si tu as reconstruit par importation du shema existant, elles en font parties...

L'importation d'un shema existant est connue pour ne pas fournir un shema très propre (pour ne pas dire un shema particulièrement pourri). Il est important de savoir si tu es parti depuis un shema.yml pour générer la base originel. Retrouver se ficher va t'éviter quelques heures de travail...

Modifier une base de données : "à la hussarde", en production, est l'excellence de ce qu'il ne faut surtout pas faire. Comment as-tu géré ces modifications au niveau de ton modèle ?

Je pense que le mieux, si tu ne peux retrouver ton fichier originel, sera de le reconstruire, à la main, à partir des objets de base de ton modèle, que tu as dans le dossier lib/modeles/doctrine/base. Attention, ceux qui sont actuellement présents dans ta version local sont ceux généré a partir du shéma récupéré et faux. Ils ne faut donc pas les utiliser ! Il faut repartir de ceux que tu as sur ton serveur. A la lecture de ces fichiers tu devrais pouvoir recréer un shema.yml qui va te rendre le même modèle, notamment au niveau des noms des relations. Laisse de côté les tables de sfGuard, elles devraient se recréer correctement seul.

Quant à tes modifications ultérieur, il faudra les rajouter correctement à la mais dans le shema, mais je ne suis pas capable d'en appréhender l'impact.

Le mieux étant que ces modifications n'aient été apportée à la main qu'après modification du shema.yml sur le poste initial de développement et régénération de la base sur ce même poste en comparaison des bases local et serveur, alors les objets du modèle sur le serveur sont bon, alors ton shema.yml sera relativement simple à reconstruire.

Mais surtout ne crois pas que l'importation du schéma va te donner ton shema.yml d'origine (essaye sur un projet test avec deux tables en relations, tu vas être surpris...)

[Colmea]

Merci pour toutes ces précisions.
Je craignais cette réponse. Comme dit précédemment, mon portable s'est éteint, j'ai donc perdu l'intégralité de mon projet en local.

Mais oui, je suis bel et bien parti d'un schema que j'ai fait à la main. J'ai toujours fonctionné avec ce schema, jusqu'à ce que mon ordi rende l'âme et qu'il disparaisse sur mon serveur de production (manque de bol...).

Je vais donc tenter de remettre la main sur ce fameux schema

Sinon, tu dis que modifier sa bdd en production à la main est la pire des idées. Mais je en vois pas d'autres solutions ? Habituellement quand je dois apporter une modification à la bdd voici comment je procède:

1. Je modifie mon schema en local
2. je regénère mes models et ma bdd à partir de ce schema
3. j'importe ces nouveaux models et ce nouveau schema sur mon serveur
4. j'ajoute à la main mon nouveau champ dans ma bdd sur mon serveur histoire de ne pas perdre mes données

Y a-t-il une autre solution ?
EDIT: Après relecture c'est en effet ce que tu proposes, si j'ai bien compris. Donc j'étais dans le bon.

Donc oui, je précise donc que je ne fais jamais cela (générer mon schema depuis ma bdd). C'est juste vu les circonstances :/


Dernière chose: ok le schema de SfDoctrineGuard va être regénéré, mais quid de ma relation entre ma table Membre et la table SfGuardUser ? Préciser la relation simplement dans les relations de la table Membre suffira-t-il ?

Merci pour ton aide précieuse

Colmea

[Michel Rotta]

Pour éviter tous problèmes, les relations ne doivent être écrites que d'un côté de la relation, sur une seule des deux tables concernées. Seul exception, la relation n-n qui va, elle, être écrite sur deux des trois tables.

Il n'y a donc aucun problème pour écrire ta relation avec sfGuardUser.

[Colmea]

Bonsoir,

Après quelques recherches, j'ai réussi à remettre la main sur un schema qui ne datait pas trop (une seule mise à jour à faire pour qu'il corresponde).
Seulement j'ai une erreur lors de la création de la base de donnée:

Code :

1
2
3
4
5
6
7
8
 
SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'type' doesn't exist in table.
 Failing Query: "CREATE TABLE sf_guard_user_profile
 (id BIGINT AUTO_INCREMENT, user_id INT, email VARCHAR(100),
 INDEX sf_guard_user_profile_type_idx (type), PRIMARY KEY(id)) ENGINE = INNODB"
. Failing Query: CREATE TABLE sf_guard_user_profile (id BIGINT AUTO_INCREMENT,
 user_id INT, email VARCHAR(100), INDEX sf_guard_user_profile_type_idx (type), 
PRIMARY KEY(id)) ENGINE = INNODB

Je précise que mon bon schema retrouvé ne touche pas aux tables sf_guard, donc a priori il ne devrait pas y avoir de problème leur de leur création.

Voici le Schema du plugin récupéré dans plugin/sfDoctrineGuardPlugin/config/doctrine/schema.yml:
http://pastebin.com/She7RiRm

Et voici une partie de mon schema (juste la table membre en fait, les autres sont inutiles):
http://pastebin.com/RSeXw0Sa

A noter aussi qu'après cette tentative de build général, l'erreur de départ avec l'unknown component 'permissions' est toujours présent quand je tente de me connecter :/


Je commence légèrement à désespérer

Bonne soirée

[Michel Rotta]

Je ne vois pas trop d'où vient la table sfGuardUserProfil qui n'est pas standard pour sfGuard.

Mais manifestement, il tente de créer un index sur le champ type sans que la table n'aie de colonne type... ce qui va être compliqué !

[Herode]

Envoyé par Michel Rotta

Je ne vois pas trop d'où vient la table sfGuardUserProfil qui n'est pas standard pour sfGuard.

Du plugin sfDoctrineApplyPlugin ou de sa variante sfForked(...) ?

Cela me semble étrange puisque les models ont été créés à partir du schéma qui lui-même provient de ma base de donnée qui fonctionnait très bien deux minutes auparavant (en local ET sur mon serveur de production).

Cela me semble très prévisible au contraire. Permission est un attribut du modèle qui est créé par une section 'relations' dans le schema.yml et la relation en question est portée par une table d'association : sf_guard_user <-> sf_guard_user_permission <-> sf_guard_permission.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
sfGuardUser:
  actAs: [Timestampable]
  columns:
    first_name: string(255)
    last_name: string(255)
    [...]
  relations:
    [...]
    Permissions:
      class: sfGuardPermission
      local: user_id
      foreign: permission_id
      refClass: sfGuardUserPermission
      foreignAlias: Users

Si tu as reconstitué ton schema.yml à partir de la base de données, je pense que cette relation a disparu du nouveau schema (ainsi que toutes les autres de type n-n).

Pas de relation => pas d'attribut 'permission' créé dans le modèle. Donc, quand tu as fait ton buildl avec le nouveau schéma, tu as effacé tous ces attributs.

Si je ne me trompe pas, il ne te reste qu'à répertorier les dégâts, à corriger ton schéma à la main pour y rétablir les relations n-n supprimées et à refaire un build.

[Colmea]

Merci pour vos réponses.

Comme je le disais, j'ai récupéré mon schema, donc toutes les relations. Donc logiquement sur ce point, pas de soucis.

Quant à la relation Permissions, il ne s'agit de toute façon pas d'une relation que j'ai dû faire, puisque c'est le plugin qui s'en charge, si j'ai bien compris ?

Vous me dites que cette relation viendrait du plugin sfForked...
Or il me semble avoir désinstaller ce plugin. Après vérification, il ne se trouve effectivement plus dans mon dossier plugins, ni dans mon fichier de ProjectConfiguration .
Par contre, le dossier sfForked... se trouve dans mes différentes lib (model, filters et forms).
Mais même après les avoir supprimés, j'ai toujours la même erreur :/ .

Devrais-je relancer un uninstall plugin pour être sûr ?

[Herode]

La relation 'Permissions' est déclarée dans le plugin sfDoctrineGuardPlugin. Si ce plugin est toujours en place (donc présent avec son fichier schema.yml) et si les tables qu'il décrit ne sont pas surchargées dans un autre schema.yml alors en effet, il ne devrait pas y avoir de problème.

Pour supprimer les fichiers du modèle pointant des tables inexistantes, doctrine:clean-model-files est en principe efficace.

[benhsaien]

va voir dans :

Code :

tonprojet/lib/model/doctrine

tu va trouver des fichier sf......envirent 6 fichier tu doit les supprimé puis vider le cache .

[Michel Rotta]

La méthode donnée par Herode est la méthode recommandée par symfony et la meilleur méthode possible.

La solution proposée par Benhsaien ne doit être utilisée que dans des cas extrêmes, si la méthode précédante ne marche pas et si l'on est absolument sur de ce qui est supprimé... Une bonne sauvegarde (ou un vrai versionning) du projet au préalable est indispensable.