Je suis nouveau dans les migrations, et j'essaie de vous tenir au courant généré automatiquement:
$ php app/console doctrine:migrations:diff $ php app/console doctrine:migrations:migrate
3 Réponses :
Lorsque vous dites "Table de sessions", je suppose que tu sens la table des sessions pour PdosessionStorage? (Juste pour être sûr que nous parlons de la même chose :-))
J'ai eu un problème similaire et la seule solution persistante (et non complexe) était simplement de mettre vos sessions dans une autre base de données (et mettez à jour la configuration en conséquence). Mais cela nécessite la permission de créer un DB supplémentaire.
Si vous n'avez pas cette possibilité, je vais regarder dans une autre solution, mais peut-être que ce qui précède a été mentionné pour vous: -)
Donc, vous n'avez pas la possibilité de mettre tous les éléments de PdosessionStorage (fondamentalement de la table des sessions) dans une autre base de données?
Oui mais c'est plus de problèmes que je pense. Et je ne sais pas si une connexion de DB supplémentaire est bonne pour la performance. N'a-t-il pas ajouter des frais généraux?
Vous n'avez certainement pas besoin d'utiliser une autre base de données dédiée uniquement à la table de session. Comme @sam a déjà posté la réponse ci-dessus, il suffit de configurer la doctrine pour ignorer la table de session. J'écris cela en 2020, la réponse de Sam était en 2013 et cette réponse non valide (actuellement) appartient à 2011; C'est pourquoi je ne veux pas descendre la réponse car elle peut être valide en 2011.
Je sais que je suis en retard sur cette question, mais je figureais à une suggestion.
Importer les tables de session dans vos entités. Même si vous ne l'utilisez pas via les interfaces qu'il crée, elle permettra à la doctrine de garder une trace des tables, de sorte qu'elle sait qu'ils sont là.
Voir: http://symfony.com/doc/current/cookebook/doctrine/reverse_engineering.html
Une autre option est simplement de dire à la doctrine d'ignorer la table. Vous pouvez utiliser l'option Donc, si Votre table est appelée Nous avions un grand nombre de tables à ignorer, nous avons donc pris l'approche opposée - nous avons dit à la doctrine de considérer uniquement les tables qui ont commencé avec un certain préfixe et mis en place des auditeurs Pour que toutes nos tables gérées par la doctrine avaient un préfixe. L'utilisation des auditeurs pour les préfixes de table est documentée à http: / /docs.doctrine-project.org/fr/Latest/Cookbook/sql-table-profixes.html et il y a un message aussi sur le côté symfony de celui-ci ICI . schema_filter comme décrit dans Cela post-message . sessions , ajoutez les points suivants à config.yml (symfony <4) ou doctrine.yaml (symfony> = 4):
Je peux confirmer que cela fonctionne bien dans Symfony4 si vous l'ajoutez à doctrine.yaml