Chaque commande SQL DDL est-elle réversible? [contrôle de version de base de données]

Question

Je souhaite configurer un mécanisme de suivi des modifications de schéma de base de données, tel que celui décrit dans cette réponse :

  

Pour chaque modification apportée à la   base de données, vous écrivez une nouvelle migration.   Les migrations ont généralement deux méthodes:   un " up " méthode dans laquelle les changements   sont appliqués et un " down " méthode en   les modifications sont annulées. Un célibataire ou Individual   commande amène la base de données à   date, et peut également être utilisé pour apporter   la base de données à une version spécifique de   le schéma.

Ma question est la suivante: chaque commande DDL est-elle dans un "up"? méthode réversible? En d’autres termes, pouvons-nous toujours fournir un "& down;" & méthode? Pouvez-vous imaginer une commande DDL qui ne puisse pas être "désactivée"?

S'il vous plaît, ne considérez pas le problème typique de migration de données où, pendant la procédure "up". méthode, nous avons une perte de données: par ex. changer un type de champ de datetime ( DateOfBirth ) à int ( YearOfBirth ), nous perdons des données qui ne peuvent pas être restauré.

Answer 1

sur le serveur SQL, chaque commande DDL que je connais est une paire haut / bas.

Answer 2

Hormis la perte de données, chaque migration que j'ai effectuée est réversible. Cela dit, Rails offre un moyen de marquer une migration comme "destructive":

  

Certaines transformations sont destructives   d'une manière qui ne peut pas être inversée.   Les migrations de ce genre devraient susciter   un ActiveRecord :: IrreversibleMigration   exception dans leur méthode down.

Voir la documentation de l'API ici .

Answer 3

Oui, vous avez identifié des cas de perte de données, que ce soit en les transformant ou simplement en DROP COLUMN dans le "up". migration.

Un autre exemple est que vous pouvez supprimer un objet SEQUENCE, perdant ainsi son état. Le " down " la migration recréerait la séquence, mais recommencerait à 1. Cela pourrait entraîner la création de valeurs en double par la séquence. Pas de problème si vous effectuez une migration sur une base de données vide et que vous voulez que la séquence commence à 1 de toute façon, mais si vous avez un certain nombre de lignes de données, vous voudriez que la séquence soit réinitialisée à la valeur la plus grande. actuellement en cours d'utilisation, ce qui est difficile à faire de manière fiable, à moins que vous n'ayez un verrou exclusif sur cette table.

Tout autre fichier DDL dépendant de l'état des données de la base de données présente des problèmes similaires. Ce n'est probablement pas une bonne conception de schéma en premier lieu. J'essaie simplement de penser aux cas qui correspondent à votre question.