2010-12-03 16 views
4

Je pense à déployer des migrations Doctrine dans mon environnement pour gérer les changements de base de données entre plusieurs développeurs. Je ne les ai jamais utilisés auparavant, mais j'ai fait mes recherches à ce sujet. Ma seule préoccupation à ce stade est que [pour autant que je sache] Les migrations Doctrine ne permettent pas les modifications de l'appareil. Bien que je réalise que les migrations sont pour des changements schématiques, je pense que les changements d'appareils sont tout aussi importants. Je voudrais avoir des appareils pour les tables de référence est ma base de données (ie * _type, * _source, etc), et je pense que la ligne add/delete/updates devrait être manipulée par ces migrations, car ils sont tout aussi important que tout changement structurel.Doctrine Migrations Re.

Si quelqu'un pouvait me pointer dans la bonne direction ici, ce serait très apprécié.

Mise à jour

J'explore l'idée de simplement laisser suivre SVN mes accessoires de table de référence, mais ce serait être une solution undeployable. Les tables ne pourraient pas être tronquées/re-peuplées en raison de contraintes de clé étrangère.

Répondre

2

Comme vous l'avez souligné, les migrations sont destinées à faciliter les changements structurels de la base de données, et non à manipuler les données de vos appareils conformément à celles-ci. D'après mon expérience, l'utilisation des migrations lorsqu'une application est en développement n'est pas nécessairement la plus utile, surtout si le développeur A crée une nouvelle migration et ne s'engage pas immédiatement, et que le développeur B crée également une nouvelle migration. qui (sans le savoir) est en conflit avec la migration du développeur A, puis s'enregistre immédiatement. Le développeur A vérifie sa migration peu de temps après, et vous avez deux migrations conflictuelles et le monde explose. Je dirais que le meilleur moyen (bien que plus long) de le faire serait de modifier votre schéma dans schema.yml, d'appliquer vos changements de schéma (soit avec une migration privée ou manuellement), puis de doctrine:data-dump et de valider votre données d'appareils.

Si vous optez pour des migrations en développement, vous devriez peut-être envisager d'utiliser les méthodes ->postUp() et ->preUp() de la classe Doctrine Migration pour transformer vos données in situ.

+0

Cela semble être exactement ce que je cherchais (ref http://www.doctrine-project.org/projects/orm/1.2/docs/manual/migrations/fr#writing-migration-classes:pre-et -post-hooks). Merci, monsieur Jarmin. Aussi, bien que votre approche semble être la meilleure approche, je ne suis pas sûr de la facilité avec laquelle les changements structurels réguliers seraient mis en production. – Craige

+0

Doctrine Les migrations sont vraiment cool - amusez-vous – BenLanc

+0

@MrJasmin, aussi longtemps que vous n'utilisez pas sqlite .. Doctrine: data-dump est la seule façon de faire des migrations dans sqlite. – Dziamid