Инструментарий миграции баз данных .NET

Question

Мой текущий проект для домашних животных - это библиотека миграции базы данных, не зависящая от языка ( Wizardby в Google Code). Это в значительной степени вдохновлено ActiveRecord Migrations, но имеет несколько тонкостей. Например, выполняет какой-то базовый «вывод типа», поэтому вам не нужно указывать тип столбца FK. Он также достаточно умен, чтобы генерировать сценарии «downgrade», используя только последовательность «upgrade». Хотя миграции написаны на специальном DSL, этот инструмент в первую очередь предназначен для проектов .NET. Он также не зависит от базы данных.

Вот краткий обзор синтаксиса:

  migration "Blog" revision => 1:
    type-aliases:
      type-alias N type => String, length => 200, nullable => false, default => ""

    defaults:
      default-primary-key ID type => Int32, nullable => false, identity => true

    version 1:
      add table Author:
        FirstName type => N
        LastName type => N
        EmailAddress type => N, unique => true
        Login type => N, unique => true
        Password type => Binary, length => 64, nullable => true

      add table Tag:
        Name type => N

      add table Blog:
        Name type => N
        Description type => String, nullable => false

      add table BlogPost:
        Title type => N
        Slug type => N
        BlogID references => Blog
        AuthorID references => Author

      add table BlogPostTagJunction primary-key => false:
        BlogPostID references => BlogPost
        TagID references => Tag

    version 2:
      add table BlogPostComment:
        BlogPostID references => BlogPost
        AuthorEmailAddress type => N
        Content type => String, nullable => false

    version 3:
      add table Media:
        TypeID type => Int32
        Name type => N
        MimeType type => N
        Length type => Int32
        BlogPostID nullable => true, references => BlogPost
        BlogPostCommentID nullable => true, references => BlogPostComment

      add table User:
        Login type => String, length => 200, nullable => false
        Password type => Binary, length => 64, nullable => false

        index IX_Login columns => [ID, [Login, desc]], unique => true

    version 4:
        add table Forum:
          Name type => String, length => 200, nullable => false
        add column ModeratorUserID nullable => false, references => User

    version 5:
        remove index IX_Login table => User

    version 6:
        add index IX_Login table => User, columns => [ID, [Login, desc]], unique => true

    version 7:
        BlogAuthorJunction primary-key => false:
            BlogID references => Blog
            AuthorID references => Author

        execute native-sql upgrade-resource => InsertSeedData, downgrade-resource => DeleteSeedData

Я знаю о других миграционных библиотеках, но эй, это любимый проект!

Вопрос в том, какие функции вы ожидаете от инструментальных средств миграции баз данных в целом, и что вы можете сказать об этом конкретном щенке по синтаксису?

Answer 1

Мне нравится этот синтаксис. В вашем примере вы сосредоточены на изменении структуры. Но как насчет манипулирования данными?

Очень часто, когда в процессе миграции мне приходится изменять данные (например, добавлять некоторые словарные данные).

Answer 2

Мне бы хотелось увидеть возможность проверить, что каждая ревизия была применена к базе данных. Так, например, в версии 3 добавлена ​​таблица «Медиа». С тех пор версии 4 и 5 были добавлены в базу данных, но где-то вдоль строки «Johnny Q Expert» удалил таблицу «Media». Теперь идет версия 6, в которой необходимо изменить таблицу 'Media' (которая больше не существует) - может быть полезна функция проверки, которая обеспечивает кульминацию всех изменений, внесенных в версиях с 1 по 5, в базу данных, поэтому следующая версия может быть применяется правильно.

Answer 3

Судя по всему, я должен сказать, что за ним легко следить, и в целом структура выглядит довольно чисто.

Самые большие возможности, которые я ищу в чем-то подобном, следующие:

1. Возможность внесения изменений в транзакцию для отката в случае возникновения проблемы. (Целостность данных или иное)
2. Возможность видеть фактически сгенерированные сценарии SQL в случае необходимости
3. Автоматический откат, если происходит сбой до последней версии

У меня есть другие требования, касающиеся перемещения ключей, индексов и тому подобного, но, похоже, вы уже справились с этим. Для меня это действительно сфокусировано на средствах управления фактическим исполнением и быстром, надежном плане возврата!