J'avoue que je comprend pas vraiment pourquoi ça ne marche pas.
Tu es bien plus expérimenté que moi tu auras peut être une solution.
Version imprimable
J'avoue que je comprend pas vraiment pourquoi ça ne marche pas.
Tu es bien plus expérimenté que moi tu auras peut être une solution.
Je pense que la génération des objets ne c'est pas faîtes correctement.
En mode développement, il convient de modifier le shema.yml et d'en régénérer les objets (form, filter, et modèle) ainsi que la base qui va avec.
Les migrations ne sont pas à utiliser ici. Ils n'interviennent que pour le passage d'une application (qui fonctionne sur la base de test) sur le serveur de production, et encore, après de nombreux tests.
Essaye de régénérer ta base et tous les objets qui vont ensembles.
Merci pour vos réponses.
C'était bien un problème de cache... Le symfony cc ne vide pas le query cache de doctrine...
J'aurai pu chercher pendant des jours encore...
Comment ça se fait que je n'ai trouvé aucun post même sur le forum symfony parlant de ça?
D’ailleurs je crois que symfony ne propose aucune commande pour vider ce cache.
Sinon, j'ai du utiliser la migration car notre serveur de test est identique au serveur de prod afin d'avoir les mêmes données si le client rencontre un problème. Donc pour ne pas tout perdre, le plus simple c'est la migration.
Encore merci!
La bonne idée est de travailler sur une architecture à trois niveaux.
Le développeur, avec se propre base peuplée avec des fixatures.
Le serveur de test qui a une base proche de celle de l'exploitation
Le serveur d'exploitation.
En prime, on peut intercaler un serveur de validation permettant aux utilisateurs de valider les modifications. Et un serveur de préproduction, identique au serveur de production, il permettra un ultime test avant la mise en production.
Pour ce qui est de la base de donnée. L'idée est de travailler sur le poste de dev, de générer la base à partir du shema. Une fois le dev testé niveau développeur, il faut utiliser, sur le poste développeur la version actuel de la base et la version nouvelle. Avec les commandes il est alors possible de générer les migrations. Elles sont souvent à corriger pour prendre en compte la migration des données. Une fois le fichier de migration créé et testé sur le poste développeur, ont peut le faire sur le poste de test, de validation, de pré-prod et enfin de production. Dans les cas de configuration extrêmes.
Merci pour ce partage.
Ca m'a l'air d'une bonne approche minimisant énormément les problèmes lors de la mise en production finale.
Concernant mes questions sur le cache, tu as une idée?
Je n'ai jamais eu de problème de cache avec Doctrine.
Je n'ai jamais rien lu concernant un problème de cache avec Doctrine.
Mon idée reste que tu as utilisé un moyen non prévu et non recommandé pour générer tes modifications qui a entrainé ce problème, probablement parce qu'une partie du code doctrine n'a pas été correctement initialisé.
Refait une génération de toute la base depuis ton shema sur un poste de développement, utilise de petites fixtures pour tester et écris ta migration en fonction de ce que tu auras généré. Je n'ai pas, à priori, de meilleur solution. Et celle-ci à le mérite de fonctionner.
En fait j'avais suivi les conseils de ce billet :
http://www.moduleutile.com/2011/02/s...migration.html
Il ne préconise alors pas une bonne solution?
Je n'ai pas la prétention de connaître tous les blogs autour de symfony.
Par contre, la méthode exposée me semble un peu rapide sur la mise en oeuvre et oublier une étape, la première, celle qui consiste à générer la base future directement à partir du shema. Je ne travaillerais ni ne conseillerais cette méthode.
Ok, merci pour ton avis :)