Dimensional Jumping

Fill my heart with the world’s ashes, the dust that settles into the crevices of that old, gray house. A silent owl, hard, and unmoving, standing guard over stalks of sunflowers. The winds sending…

Smartphone

独家优惠奖金 100% 高达 1 BTC + 180 免费旋转




Versionando seu Banco de Dados com Liquibase

Definitivamente o Liquibase não é uma novidade, mas sempre que ele torna minha vida mais fácil com a criação da estrutura dos meus bancos de dados relacionais — especialmente no ambiente de desenvolvimento — , fico com vontade de falar sobre ele para todo mundo. Então não preciso dizer que já faz um tempo considerável que me devo escrever sobre o assunto.

Provavelmente você já esteve em um cenário onde era necessário criar uma base de dados nova para preparar um ambiente e quando foi ver era preciso executar diversos scripts SQL com uma quantidade enorme de linhas, ou até mesmo criar mais de uma base de dados ao mesmo tempo. Isso pode se tornar uma tarefa muito cansativa. Existe a possibilidade de esquecer de executar aquele script que fica lá no meio de outros muitos. Definitivamente isso é bem chato. E em um cenário mais crítico: changes em produção? Se esse trabalho não é feito por um DBA, provavelmente será você o responsável por executar essas ação e isso pode ser bem arriscado. Isso sem falar na eventual necessidade de rollback.

Vamos deixar os problemas tradicionais relativos a changes na base de lado por um minuto e começar a pensar simplesmente na possibilidade de versionar os scripts de banco de uma forma parecida como fazemos com o código da aplicação. Os scripts também passariam a ter uma sequencia de execução definida de fato. De quebra ainda seria mais fácil fazer rastreabilidade das alterações.

O Liquibase veio para solucionar todos esses problemas. Com ele será possível versionar as alterações do banco, poderemos fazer rollbacks com muito mais facilidade e ainda teremos uma rastreabilidade do que foi executado e quando. Ah. Também passaremos a garantia de que não importa quantas vezes o script seja executado, nada quebrará. Como? Pela versão ué. Se ele já executou uma versão, não executará outra vez aquela mesma versão.

O Liquibase não é a única solução do tipo no mercado. Existe também outras ferramentas como o Flyway, por exemplo. Porém, como estou mais acostumado com o primeiro, nada mais justo que começar por ele.

Então vamos ao que interessa…

O Liquibase dá suporte a diversas bases de dados. A lista abaixo são os principais DBs suportados.

Para criar a estrutura das suas tabelas você pode fazer de quatro formas: XML, YAML, JSON e SQL. Abaixo estão alguns exemplos que eu peguei do próprio site do Liquibase.

Francamente SQL é minha opção favorita. Apesar de já ter utilizado também o formato YAML e achar bem interessante já que não ficamos tão amarrados a eventuais pequenas mudanças no SQL de um DB para outro.

Agora que já entendemos um pouco do básico para a utilização do Liquibase, vamos enfim colocar a mão na massa e fazer uma pequena aplicação. Para isso faremos uma aplicação em SpringBoot e Maven e utilizaremos o H2 em memória para persistir os dados.

O modelo que utilizaremos será o seguinte.

2. Adicionar as dependências necessárias no pom.xml

3. Adicionando as configurações no application.yml do SpringBoot

Com o passo 3 feito, já podemos de fato pensar na nossa estrutura do banco de dados. Para esse exemplo escreveremos nosso próprio SQL e deixaremos o Liquibase responsável por gerenciar essa criação. Vale inclusive notar que o ddl-auto do Hibernate está apenas como validate. Portanto ele não fará nenhum tipo de alteração na base e apenas verificará se está de acordo com o mapeamento feito nas classes de modelos.

4. Criar o changelog e adicionar os SQLs que serão utilizados

Será necessário criar dentro de resource a pastas db/changelog e db/changelog/migrations

Dentro de db/changelog será criado o um arquivo chamado db.changelog-master.yaml. Esse será o arquivo onde será indicado quais arquivos serão utilizados pelo Liquibase como base para criação do BD. Para esse exemplo, ele ficará da seguinte forma:

E dentro de db/changelog/migrations ficará os arquivos SQL.

Repare que a primeira linha identifica que esse realmente será um arquivo utilizado pelo Liquibase e reforça que o padrão utilizado será o SQL

O segundo pondo de atenção é a configuração do changeset. É nessa linha que será informado quem fez e o número da versão dessa change. Essas informações serão armazenadas em tabelas de metadados do Liquibase e esses dados formam uma chave composta de modo que não pode existir dois scripts diferente com a mesma combinação de usuário+versão

E por ultimo as linhas de rollback. Essa é uma das coisas mais bacanas da ferramenta como um todo. Como eu posso executar um comando da biblioteca do Liquibase e efetuar o rollback de uma determinada versão, será executado exatamente o que está sendo definido nessas linhas.

A estrutura do projeto até o momento está da seguinte forma

Nesse momento já é possível rodar a aplicação sem que dê erro.

5. Reta final! Agora é criar as classes de modelo e os Repositórios.

Classe imagem

Classe Produto

Repositório de Imagem

Repositório de Produto

E por fim, adicionar a anotação EntityScan no na classe da Aplicação

E pronto. A estrutura do banco está sendo criada pelo Liquibase e a aplicação está devidamente mapeada.

Agora o passo final é criar um teste básico para confirmar que está tudo de acordo.

Executando o teste, se torna possível testar e comprovar que tudo foi criado corretamente e que as informações estão sendo persistidas sem maiores problemas.

Uma das boas práticas que já está no nosso cotidiano do desenvolvimento é o controle de versão de código. Hoje vimos que é possível ter esse mesmo controle nas alterações da nossa base de dados utilizando uma ferramenta como o Liquibase. Dessa forma fica mais fácil controlarmos qualquer tipo de alteração da nossa base de dados, nos proporcionando um pouco mais de segurança para realizar esse tipo de atividade.

No próximo post vamos aprofundar um pouco mais no Liquibase e ver algumas funcionalidades que ele nos proporciona.

Espero que este post tenha sido verdadeiramente útil. Qualquer dúvida ou sugestão, por favor não hesite em escrever nos comentários.

Até a próxima.

Add a comment

Related posts:

Il TAO delle DAO

Il modo migliore per spiegare cosa sia una DAO è probabilmente quello di definirla in relazione alle organizzazioni tradizionali. Le organizzazioni tradizionali sono generalmente governate da un…

RISE Node v1.1.0t in Testnet

The newer version features several improvements and more detailed information will follow once 1.1.0 is released in mainnet. Furthermore, the new RISE 1.1.0 version uses a different SQL library…

A Graphic Representation Of What Your Spiritual Companion Collection Might Look Like

Our spiritual companions are invisible but they cluster around us and permeate our bodies. Judging by the images we receive from them they can be beautiful or grotesque. The underlying truth is that…