Gestion de la structure de la base de données dans plusieurs succursales

La couche de base de données d'une application est un être distinct et n'est contrôlée que par les migrations. Lors de la création de nouvelles migrations, n'oubliez pas de rendre réversible la transformation prévue de la structure d'une base de données. Bien sûr, dans les cas extrêmes, nous pouvons augmenter la valeur de la base de données. Migration irréversible dans le vers le bas méthode. Cela nous informera également du fait que la migration ne peut pas être annulée. Il existe différents types de changements que nous effectuons lors de la migration - création, modification et suppression de tables, de colonnes ou d'index. Les opérations de suppression et de modification sont les plus sensibles aux changements. Pourquoi ? Considérons le scénario suivant : nous travaillons avec la branche master, qui est notre chemin de travail principal. Nous avons actuellement une table :

 classe CreateArticles < ActiveRecord::Migration
   def change
     create_table :articles do |t|
       t.string :name
       t.text :description
       t.string :status, null : false
       t.timestamps null : false
     end
   end
 end

Notre Article comporte de telles validations qui requièrent la présence de nom, description et statut attributs.

 classe Article < ActiveRecord::Base
   valide :name, présence : true
   valide :description, présence : true
   valide :status, présence : true
 fin

Nous mettons en œuvre des changements dans notre articles table sur caractéristique et nous supprimons la branche de développement statut colonne.

<classe RemoveStatusColumnFromArticles < ActiveRecord::Migration
   def change
     remove_column :articles, :status, :string
   end
 end

Nous exécutons la migration :

 $ [exemple/caractéristique] : bundle exec rake db:migrate
 == 20150605120955 RemoveStatusColumnFromArticles : migration ===================
 -- remove_column(:articles, :status, :string)
   -> 0.0717s
 == 20150605120955 RemoveStatusColumnFromArticles : migré (0.0718s) ==========

Le schéma d'une base de données est modifié :

diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #

Il est fortement recommandé d'enregistrer ce fichier dans votre système de contrôle de version.

-ActiveRecord::Schema.define(version : 20150605120350) do
+ActiveRecord::Schema.define(version : 20150605120955) do
  createtable "articles", force : :cascade do |t|
    t.string "nom"
    t.text "description"
- t.string "status", null : false t.datetime "createdat", null : false
    t.datetime "updated_at", null : false
  fin

fin

Ensuite, nous validons les modifications dans le fichier caractéristique branche. Pour simuler ce problème, nous passons de la branche actuelle à la branche master. La structure de base a été modifiée par la migration, qui supprime la branche statut dans la colonne caractéristique branche. Essayons d'utiliser la commande suivante :

Article.create !(name : "Kaboom", description : "Lorem ipsum...", status : "active")

Que se passera-t-il après l'exécution de l'action mentionnée ci-dessus ? code? L'erreur : ActiveRecord::UnknownAttributeError : attribut "status" inconnu pour l'article sera soulevée à cause de l'incompatibilité de la version de la structure d'une base de données. Avant de changer la branche en master, nous devrions revenir sur une migration qui supprime le fichier statut de la colonne Article table.

Que pouvons-nous faire pour vérifier si nous devons annuler certaines migrations avant de changer de branche ? Avec l'utilisation du système de contrôle de version (ici c'est git), nous pouvons vérifier notre travail en créant un alias utile :

~/.gitconfig
 [alias]
  migrations = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]' ; } ; f"

Exécution de la git migrations master feature La commande permet d'obtenir la liste des versions de migration, qui se trouvent sur le site caractéristique et qui ne peuvent être trouvées sur le site maître.

 $ [example/feature] : git migrations master feature
 20150605120955

Grâce à ces informations, nous pouvons facilement annuler les modifications apportées à la structure de la base de données avant de passer au niveau maître.

 $ [exemple/caractéristique] : bundle exec rake db:migrate:down VERSION=20150605120955
 === 20150605120955 RemoveStatusColumnFromArticles : reverting ===================
 -- add_column(:articles, :status, :string)
   -> 0.0009s
 == 20150605120955 RemoveStatusColumnFromArticles : reverted (0.0045s) ==========

Une autre chose à faire après le retour en arrière de la migration est de restaurer l'état d'un schéma de base de données.

$ [example/feature] : git status
Sur la branche fonctionnalité
Les modifications ne sont pas mises à disposition pour le commit :
 (utiliser "git add ..." pour mettre à jour ce qui sera livré)
 (utiliser "git checkout -- ..." pour supprimer les modifications dans le répertoire de travail)

modifié : db/schema.rb

aucun changement ajouté au commit (utiliser "git add" et/ou "git commit -a")
$ [example/feature] : git checkout db/schema.rb
$ [exemple/caractéristique] : git status
Fonctionnalité sur la branche
rien à livrer, répertoire de travail propre

Nous pouvons maintenant facilement passer à l'option maître branche.

L'exemple donné n'est pas un problème compliqué à résoudre, mais il devrait vous aider à réaliser à quel point il est important de maintenir la structure d'une base de données lors d'un changement de contexte de travail.