Pergunta

Meu projeto de estimação atual é uma biblioteca de migração de banco de dados independente de linguagem ( Wizardby em Google Code). É muito bonito inspirado pelo ActiveRecord migrações, mas tem algumas sutilezas. Por exemplo, faz algum "tipo de inferência" básico para que você não tem que especificar o tipo de uma coluna FK. Também é inteligente o suficiente para gerar scripts "downgrade" dadas apenas "upgrade" seqüência. Embora as migrações são escritos em uma DSL especial, esta ferramenta é destinado principalmente a projetos .NET. É também de banco de dados independente de plataforma.

Aqui está uma visão rápida da sintaxe:

  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

Eu estou ciente de outras bibliotecas migração para fora lá, mas hey, é um projeto de estimação!

A questão é: quais as características que você espera de kits de ferramentas de migração de banco de dados em geral, e o que você pode dizer sobre este particular sintaxe-wise filhote de cachorro?

Foi útil?

Solução

A partir da aparência dele que eu tenho que dizer que farily é fácil de seguir e em geral a aparência estrutura muito limpo.

As maiores características que eu estou procurando em algo como isso são os seguintes.

  1. Capacidade de mudanças faz em uma transação para reverter deve haver um problema. (A integridade dos dados ou de outra forma)
  2. Capacidade de ver os scripts SQL gerados reais em caso de necessidade surgir
  3. reversão automática, se ocorrer uma falha para a última versão

Eu tenho outros requisitos relativos à movimentação de chaves, índices, e os tais, mas parece que você tem que já tratadas. Para mim é realmente focado nos controles em torno da execução real, e uma rápida, plano de backout sólida!

Outras dicas

Eu gosto desta sintaxe. Em sua amostra você focada em mudar a estrutura. Mas o que sobre manipulação de dados?

É muito frequentemente quando na migração eu tenho que modificar dados (por exemplo, adicionar alguns dados dicionário).

Eu gostaria de ver a capacidade de verificar que cada revisão foi aplicada a um banco de dados. Então diga, por exemplo, a versão 3 adicionado a mesa 'Media'. Desde então versões 4 e 5 foram adicionados ao banco de dados, mas em algum lugar ao longo da linha 'Johnny Q Especialista' excluídos da mesa 'Media'. Agora vem a versão 6, que precisa de alterar a tabela 'Media' (que já não existe) - uma função de verificar poderia ser útil que garante o culminar de todas as alterações feitas nas versões 1-5 estão presentes no banco de dados para a próxima versão pode ser aplicado correctamente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top