web-dev-qa-db-fra.com

Gestion des conflits dans schema.rb créé par l'opération Git

J'ai créé une migration, j'ai lancé rake db:migrate, ce qui a modifié mon numéro de version db/schema.rb. Ensuite, j'ai fait un git fetch Origin master et vu qu'il y avait des changements chez les membres de mon équipe. J'ai donc fait un git stash et un git rebase FETCH_HEAD, suivis d'un git stash pop. Cela a entraîné un conflit dans db/schema.rb sur le numéro de version. 

Upstream>>>
ActiveRecord::Schema.define(:version => 20110930179257) do
===========
ActiveRecord::Schema.define(:version => 20110930161932) do
<<<Stashed

Je pense que le correctif approprié serait d’incrémenter manuellement le numéro de version à un niveau supérieur à celui en amont.

Est-ce raisonnable ou une mauvaise nouvelle?

Merci, Max

ruby-on-railsgitmigration
51
maxenglander

Si votre base de données actuelle a le schéma correct, vous devez:

  • Exécuter les migrations en attente (le cas échéant)

    rake db:migrate

  • Remplacez votre schema.rb à partir de votre schéma de base de données actuel

    rake db:schema:dump

  • Et commettre

87
Wizard of Ogz

Lorsque je me trouve dans ce conflit, je migre simplement la base de données. Qu'il y ait ou non des migrations en attente, le conflit sera corrigé.

18
Sean McMills

Selon cette réponse , un conflit est garanti. L'utilisateur doit fusionner manuellement et définir la version comme la plus élevée des deux.

7
lulalala

Voici ce que je fais lorsque la fusion de maître dans ma branche de fonctionnalité échoue lors de conflits dans db/schema.rb:

$ git merge --abort
$ git checkout master
$ rake db:drop db:create db:migrate
$ git checkout -- db/schema.rb
$ git checkout my_feature_branch
$ rake db:migrate
$ git add db/schema.rb
$ git commit -m 'Updated schema'
$ git merge master
2
Mark Kreyman

~/bin/update-schema-rb:

#!/usr/bin/env bash

git co master
bin/rake db:reset db:seed
git co -
bin/rake db:migrate
1
Dorian

Je pense que la meilleure approche consiste à faire rake db:drop db:create db:migrate pour régénérer le schéma en utilisant des migrations qui n'existent que sur la branche actuelle. De cette façon, les migrations d'autres branches ne se retrouveront pas dans votre fichier de schéma et vous donneront mal à la tête plus tard - au cas où vous changeriez beaucoup de branches.

0
Dr.Strangelove

tldr

Acceptez la version en amont et exécutez rake db:migrate comme vous le feriez normalement.

pourquoi est-ce la voie à suivre

Ne vous inquiétez pas des migrations que vous avez créées (qui se trouvent sous la version amont 20110930179257). ActiveRecord utilise une table schema_migrations dans laquelle sont placées toutes les migrations exécutées. Si vos migrations ne figurent pas dans la liste mais dans le répertoire db/migrate, ActiveRecord les exécutera. 

Voici le tableau afin que vous puissiez mieux le visualiser:  schema_migrations table

Il est tentant de penser qu’il s’agit en fait de la ligne suivante: ActiveRecord::Schema.define(:version => 20110930179257) Qui définit la dernière exécution de la migration. Aucune migration dont la version est inférieure ne sera exécutée. Ce n'est heureusement pas vrai. Rails exécutera toutes les migrations qui se trouvent dans le dossier db/migrate et non encore dans la table schema_migrations.

0
Adam Sibik

Une option consiste à avoir un script de version manuelle qui est uniquement additif. Là tu veux des conflits. Le schéma est quelque chose qui vous mordra si vous ne gardez pas le contrôle. Donc, une fois mordu, deux fois timide, la conservation des informations de schéma et de recherche (liste des types de clients) avec un schéma de gestion de changement additif ne me dérange pas.

0
Adam Dymitruk