Banco de Dados Evolutivo – Parte 8

Nesse post da Série, vamos aprender a usar o comando RollbackCount. Esse comando é um dos tipos de Rollback permitidos pela ferramenta de versionamento de banco de dados Liquibase


Antes de executarmos uma alteração realmente válida na nossa base de homologação para depois replicarmos em ambiente de produção, faremos um teste usando o comando Rollback. Esse comando (como já foi dito anteriormente na Parte 4 da série de Post) é responsável por desfazer uma refatoração. Isso pode ocorrer ou por motivo de essa refatoração ser de caráter destrutivo para o sistema ou por ser válido voltar a trabalhar com a estrutura anterior à alteração.

O Liquibase tem, para alguns changesets simples como Create Table e Add Column, o é definido Rollback automaticamente. Já para alterações complexas como Merge Column ou Add Lockup Table é necessário na construção do arquivo XML definirmos o Rollback. Veremos como proceder nesses casos mais tarde.

Existem várias variantes do comando Rollback. Nesta série iremos exemplificar duas delas: O RollbackCount <valor> e o Rollback <tag> (para mais informações sobre este comando vide documentação).

O RollbackCount <valor> trabalha com base na quantidade de changesets que você quer/precisa retroceder. Para isso ele faz um simples SELECT na tabela databasechangelog, ordenando os registros de forma decrescente e exclui o número de linhas que forem passadas de parâmetros (lembrando que cada linha dessa tabela representa uma alteração executada na base de dados, logo, as mudanças correspondentes serão desfeitas).

Já o comando Rollback <tag> trabalha com base em versões de alterações. De forma resumida, já que vamos aprofundar mais a respeito desse comando mais à frente, ele faz com que o banco de dados volte a uma versão em que estava anteriormente.

Usaremos o comando RollbackCount para deletar a tabela teste_liquibase que foi criada na Parte 7 desta série. Use para isso os código da Listagem 1.

java -jar C:\liquibase-3.0.8-bin\liquibase.jar --defaultsFile=C:\liquibase-3.0.8-bin\liquibaseHomolog.properties rollbackCount 1

Listagem 1. Comando usado para deletar a tabela teste_liquibase da base AdventureWorks_Homolog.

Captura de Tela 2015-06-29 às 9.08.45 PM
Figura 1. O database AdventureWorks_Homolog não mais possui a tabela teste_liquibase.

Observe que depois de executado o comando a tabela teste_liquibase não mais existe no database AdventureWorks_Homolog e que o registro de criação dessa tabela deixou de existir na tabela de controle databasechangelog do Liquibase (Veja as Figuras 1 e 2).

 

Captura de Tela 2015-06-29 às 9.10.34 PM
Figura 2. A tabela de controle databasechangelog não mais possui o registro relacionado a criação da tabela teste_liquibase.

No próximo post da Série Banco de Dados Evolutivo você entenderá mais a respeito das refatorações com as quais o Liquibase trabalha e verá como implementar uma Bundled Change addColumn.

Anúncios

4 comentários sobre “Banco de Dados Evolutivo – Parte 8

  1. Roberto

    Prezado Arthur,

    Acredito estar com um problema pois no passo 4 ao baixar o banco AdventureWorks_Homolog não conseguir restaurar o backup acredito pelo fato do meu SQL ser o 2008. No entanto segui todos os outros procedimentos e consegui fazer a plicação funcionar e criar a entidade em minha base local que não é a AdventureWorks_Homolog.
    Vendo agora o post 8 compreendo que esse banco não é só para teste com a ferramenta mais sim a sua base de dados do liquibase. Teria como disponibilizar o script da base ou se existe um AdventureWorks_Homolog versão 2008?

    Curtir

    1. Roberto,

      As bases AdventureWorks_Homolog e AdventureWorks_Prod nada mais são que duas cópias idênticas da base AdventureWorks2014.

      Você pode usar a base de dados e o banco que você possui. O que você precisa fazer é restaurar o banco que possui (AdventureWorks2008) duas vezes. Uma delas com o nome AdventureWorks_Homolog e a outra com o nome AdventureWorks_Prod (você pode mudar o nome da base no próprio restore, ou somente renomeá-la após o término do processo).

      Estamos fazendo isso porquê precisamos simular um ambiente real. Duas bases, uma ligada à aplicação, e outra para desenvolvimento. O que for feito em desenvolvimento precisará ser replicado em produção.

      Espero que tenha sanado tua dúvida! Se não, estou a disposição!

      Curtir

  2. Roberto

    Ok Arthur estava entendendo errado, não havia percebido que as tabelas DATABASECHANGELOG e DATABASECHANGELOGLOCK também foram criadas em minha base, tinha me atentado apenas a geração da [teste_liquibase].
    De toda forma o passo 8 foi executado e de pois voltei a testar executando o 7 e 8 novamente. =D
    Minha duvida agora é quanto a usabilidade do programa no dia a dia. Gostaria de saber se toda vez que eu fizer a alteração tirei que criar o xml para alterar a base ou se quando eu fizer a alteração na base ele já vai criar o xml, versionando assim o banco ?

    Curtir

    1. Esse é o “problema” do Liquibase.

      Você, como DBA, deverá, para todas as alterações, criar um arquivo XML e apontá-lo dentro dos respectivos masters.

      A ferramenta é ÓTIMA. Mas por ser uma versão free, esse é o pequeno preço que temos que pagar.

      Mas mais para frente, quando eu mostrar a bundled change SQL você verá que não é tão complexo quanto parece!

      Obrigado, novamente pelo crédito ao material e ótimos estudos!

      Qualquer coisa é só chamar! 😀

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s