Discussion :

[akito]

Bonjour!

Je constate dans la barre d'outil qui affiche les requetes qu'il manque un champs après un getObject.

Il me semble que normalement, le select doit contenir tous les champs du schema?

Ce champs manquant est un champs que je viens d'ajouter, donc après coup.
J'ai re build les classes et j'ai bien ajouter le champs en db avec la ligne de commande migration.

Il-est ce qu'il y a un endroit (une classe, config), ou je dois verifié qu'il n'y a pas une restriction dans la selection de certains champs uniquement?

Merci!

[Joauc]

Normalement si tu as re build la classe ton champs devrait apparaitre.
Tu as essayé le de vider le cache de symfony?
Sinon nul part tu as de unset() sur ce champ ?

[akito]

Merci pour ta réponse.

En effet, j'ai fait un ./symfony doctrine:build --all-classes
J'ai vérifié les classes bases et il y a bien mon nouveau champs.
J'ai également fait un ./symfony cc

Après la migration, il y a bien aussi le champs en db.

Non il n'y a pas de unset sur ce champs... Mais de ce que j'ai vu, le unset de change que le résultat final, il y a tout de même le champs dans la requete.

Est-ce qu'il n'y a pas un endroit ou peut être définit de ne sélectionner que tel et tel champs? C'est un projet que je reprends donc ça a très bien pu se faire mais de ce que j'ai pu voir je ne vois rien en ce sens.

Encore merci pour ton aide!

[Joauc]

si ton champs est dans les classes bases c'est vraiment bizarre.
Tu as vérifié tous les fichiers bases ou juste celui du model?

Sinon si des modif on était faites pour exclure certain champs c'est dans les fichiers de /lib

[akito]

J'ai vérifié le fichier BaseSfGuardProfile et je vois bien mon nouveau champs.
C'est un champs de type bool et d'ailleurs, en backend quand je modifie l'utilisateur en cochant cette nouvelle case, j'ai bien la modification qui se fait en base de données.
Par contre, quand je reviens sur la fiche de consultation ou de modification, je ne vois pas la bonne donnée, et ceci est verifié dans le select du debug.
Donc le problème se trouve vraiment au niveau de la requete de select...

Sinon tu dis que les modifs sur les champs se font dans le dossier /lib
Je suis sous doctrine, donc ça serait dans /lib/model/doctrine/maClasse.php?
Je n'ai rien vu en ce sens ni dans maClasseTable.php

D'ailleurs vu que c'est un nouveau champs, il ne peut pas être exclu explicitement. Donc je pensais plutot qu'il y avait à un endroit une selection de seulement X champs.

Merci pour ton aide

[akito]

J'ai peut être une piste :

Dans ma table sf_guard_user_profile, je vois un champs preferences.

Ce champs n'est pas dans le schema, il est pourtant dans un fichier de migration.

Ce champs n'est pas non plus présent dans le model (base).

Donc je me demande comment il peut être affiché... Ca veut surement dire qu'il y a une requete "home made" non?

Est-ce que tu as une idée?

[Joauc]

D'ailleurs vu que c'est un nouveau champs, il ne peut pas être exclu explicitement. Donc je pensais plutot qu'il y avait à un endroit une selection de seulement X champs.

C'est mon avis aussi. Tu as regardé du côté des action executeShow et executeEdit si le select retourné tout les champs?

sinon BaseSfGuardProfile ça vient du plugin sfDoctrineGuardPlugin ?

[akito]

Je te colle ici le résultat du debug de la tool bar :
http://pastium.org/view/0403d3e4f560...b32053c709e415

Tu peux voir la requête retourné sans mon nouveau champs qui est is_ce

Donc dans les appels, tu peux voir que c'est appelé depuis action.php.

Concernant le champs preference, tu as une idée de comment cela peut fonctionner si il n'est ni dans le model, ni dans le schema?

Sinon, oui ma classe c'est bien pour étendre le module baseguarduser du plugin sfDoctrineGuardPlugin

[Joauc]

concernant le champs préférence je sèche j'ai jamais vu un champs appelé qui n'était pas dans le schéma.

Sinon est-ce que tu peux montrer ton fichier action.class.php?

[akito]

je comprends pas moi non plus comment le champs préférence peut être appelé dans le requete si il n'est pas dans le schema/model.

Ca voudrait dire que symfony sélectionne tous les champs de la table. Pourtant ce n'est pas le cas puisque je n'ai pas mon nouveau champs. A moins qu'il y a vraiment un gros problème de cache, mais je l'ai bien vidé avec un ./symfony cc.

J'ai cherché voir si y avait pas un cache spécifique à doctrine pour les requetes et j'ai bien desactivé le cache dans le settings.yml

voici mon fichier action :
https://gist.github.com/1219230

Je ne pense pas qu'il va beaucoup t'aider à y voir plus clair car ça fait un appel de sfGuardUser et c'est dans la configuration qu'est appelé le profile.
Donc je te colle aussi le sfGuardUserForm qui dans le configure fait l'appel au profil avec $this->getObject()->getProfile()
https://gist.github.com/1219244

Merci pour ton aide

[Joauc]

Je ne pense pas qu'il va beaucoup t'aider à y voir plus clair car ça fait un appel de sfGuardUser et c'est dans la configuration qu'est appelé le profile.

Effectivement...

Vu tes fichiers ça doit venir de la méthode getProfile() c'est la seule piste que je vois. Elle retourne bien tout les champs ?

Pcq ça peut pas être un problème de nom de ton champ sinon il ne s'enregistrerait pas. Si ça venait de tes actions les autres champs du profile ne s'afficheraient pas non plus je pense. Tes forms ont l'air correctes.

Franchement à part la méthode getProfile qui ne retourne pas tout les champs je vois pas. Après je suis peut être passer à côté de quelque chose mais tout de suite c'est la seule chose qui me vient.

[akito]

La méthode getProfile est une methode magique
Donc elle est juste en commentaire dans BasesfGuardUser.

C'est bien cette methode qui ne fait pas la bonne requete mais vu que c'est une methode magique, elle devrait tout sélectionner


voilà un ptit extrait de la doc du plugin. En gros tu definis dans le schema ta classe sfGuardUserProfile avec les champs supplémentaire, et ensuite getProfile est censé te fournir les champs.

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
 
The `sfGuardUser` model is quite simple. There is no `email` or `first_name`
or `birthday` columns. As you cannot add methods to the class, the `sfAuthPlugin`
gives you the possibility to define a user profile class.
 
By default, `sfGuardUser` looks for a `sfGuardUserProfile` class.
 
Here is a simple example of a `sfGuardProfile` class that you can add to `schema.yml`:
 
    sf_guard_user_profile:
      _attributes: { phpName: sfGuardUserProfile }
      id:
      user_id:     { type: integer, foreignTable: sf_guard_user, foreignReference: id, required: true, onDelete: cascade }
      first_name:  varchar(20)
      last_name:   varchar(20)
      birthday:    date
 
You can now access the user profile via the user object:
 
    $this->getUser()->getGuardUser()->getProfile()->getFirstName()
 
    // or via the proxy method
    $this->getUser()->getProfile()->getFirstName()
 
The `getProfile()` method gets the associated user profile object or creates a
new one if none already exists.

[akito]

J'ai fait une requete toute simple en ligne de commande :

./symfony doctrine:dql "FROM SfGuardUserProfile WHERE SfGuardUserProfile.id=4

Résultat, j'ai tous les champs.

Donc le problème est bien côté symfony mais je ne sais pas ce qui peut enlever ma colonne...

[Joauc]

Franchement la je ne sais pas quoi faire.
Si le problème venait de ton schéma tu aurais une erreur lors du re build.

A moins que cette méthode getProfile n'arrive pas a gérer les checkbox essaie juste pour voir si tu remplaces la ckeckbox par un champs texte s'il te met quelque chose dedans?

[akito]

J'ai d'autres champs en checkbox donc ça ne peut pas venir de là.

J'essaye de var_dumpé un peu partout.

Dans :
/lib/vendor/symfony/1.4.1/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Query.php
j'ai fait un var_dump dans la method query et j'obtiens :
"FROM SfGuardUserProfile WHERE SfGuardUserProfile.id = ?"

Ca veut dire que le champs du select sont ajouté apres :
SELECT s.id AS s__id, s.firstname AS s__firstname, s.lastname AS s__lastname, s.birthdate...

Je n'ai pas encore trouvé ce qui ajoute ces champs au select

[akito]

Bon, j'ai trouvé la cause!!

Dans Query/Abstract.php, la methode execute appel :
$query = $this->_constructQueryFromCache($cached);
Donc c'est un requete en cache.....

Donc le symfony cc ne vide pas ce genre de cache.

Tu sais comment je peux le vider?

[Joauc]

Je suis à cour d'idées vraiment désolé.
Je vois pas pourquoi ça marche pour les autres champs et pas pour celui là

[akito]

T'as du écrire avant mon dernier post.

J'avance

Donc c'est un probleme de cache sur la requete, mais je ne vois pas comment vider ce cache...

[akito]

En fait, dans ProjectConfiguration.php il y a un configureDoctrine.

Dans celui ci il y a :

Code :

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

1
2
3
4
5
6
7
8
    // activate APC
    if (extension_loaded('apc'))
    {
      $cacheDriver = new Doctrine_Cache_Apc();
      $manager->setAttribute(Doctrine_Core::ATTR_QUERY_CACHE, $cacheDriver);
      $manager->setAttribute(Doctrine_Core::ATTR_RESULT_CACHE, $cacheDriver);
      $manager->setAttribute(Doctrine_Core::ATTR_RESULT_CACHE_LIFESPAN, 3600);
    }

Voila donc le code qui active apc.

Pas terrible car ça active le cache même si dans la config on a spécifié qu'on voulait pas de cache.

[Michel Rotta]

Je me permet d'intervenir dans votre discutions.

Une chose m'étonne, c'est l'utilisation des méthodes migrates. En effet, ces méthodes ne sont à utiliser que pour migrer la base de production pour une application en production, et après avoir tester les migrations sur plusieurs jeux de données test. En aucun cas ces méthodes ne doivent être utilisée pour ajouter ou modifier un champ dans le cycle de développement, sur des données de test.

Dans ce cadre, le mieux est de recréer la base à partir du shema. Comande : "...build --all". Tu as alors une reconstruction des objets et du modèle et de la base, à l'identique. A noter la présence d'une commande pour supprimer les classe du modèle qui concernerait des tables supprimées du modèle.

Je doute que tu aies un problème de cache lié à doctrine, tu peux toujours supprimer tous les dossiers du dossier cache, sans pour autant supprimer la racine (cache).