2013-09-24 4 views
2

Disons que j'ai une application avec un tas de fichiers de migration que je suis prêt à déployer en production pour la première fois. D'après ce que je comprends, j'ai essentiellement deux options pour obtenir le db sur le serveur de production:Comment db: schema: load affecte les futures actions db: migrate

  • A - Exécuter db:migrate et avoir le cycle à travers toutes les migrations, il n'a pas encore exécuté
  • B - exécutez db:schema:load, et l'ont construit la db à partir du fichier de schéma

Je sais que B est le bon choix pour les déploiements frais, comme expliqué dans les commentaires schema.rb:

# If you need to create the application database on another 
# system, you should be using db:schema:load, not running all the migrations 
# from scratch. The latter is a flawed and unsustainable approach (the more migrations 
# you'll amass, the slower it'll run and the greater likelihood for issues). 

Ce que je me demande, c'est comment cela affecte-t-il les migrations sur le serveur de production? Par exemple, si je suis dans l'ordre suivant:

  1. Exécutez db:schema:load sur un nouveau serveur de production.
  2. Modifier mon schéma en développement et pousser à la production.
  3. Run db:migrate sur le serveur de production

Que se passera? Sera-t-il capable d'utiliser uniquement les migrations plus récentes que l'action db:schema:load, ou tentera-t-il de les exécuter toutes?

+0

Et vous n'avez pas pensé simplement à exécuter ces commandes de couple pour vous vérifier? –

+0

@MichaelSzyndel - Qui a dit que je n'y avais pas pensé? – Yarin

+0

Votre question le suggère. Si vous le faisiez, vous verriez que cela devrait fonctionner correctement (tant que la table db de migrations est remplie pendant 'schema: load' que je n'ai jamais vraiment vérifié) –

Répondre

1

Bonne question. La réponse est que seules les migrations créées après le dernier événement db:schema:load seront exécutées.

Le fichier de schema.rb a un timbre de version qui lui est associée:

ActiveRecord::Schema.define(version: 20130928225041) do ... 

Lorsque vous exécutez db:schema:load, Rails crée une nouvelle base de données en fonction de ce fichier schema.rb, et en même Remplit temps la table schema_migrations avec toutes les migrations dont le numéro de version précède celui du schéma. Donc, autant que je sache, Rails simule essentiellement toutes les migrations jusqu'à ce point, mais ne les exécute pas réellement. (Je l'ai testé en générant un fichier de migration vide, en appelant localement db:migrate, puis en insérant une erreur dans le fichier de migration avant de le déployer sur notre serveur.Sur le serveur, nous avons exécuté db:schema:load, et la migration incorrecte a été incluse dans la table schema_migrations comme si elle avait été exécutée, même si ce n'était clairement pas le cas.)