Integração FLYWAY com JARCH
O flyway é uma excelente ferramenta para versionamento de scripts de banco de dados. Por padrão, ele utiliza a tabela schema_version para fazer o gerenciamento dos scripts executados, no entanto, podemos alterar o nome da tabela através de sua API.
Nesse post, vou usar como exemplo como criar a estrutura de versionamento de estrutura e dados, na qual deve ser gerenciada por uma tabela Flyway (TB_FLYWAYSTRUCTURE).
O primeiro passo é criar a pasta (db/migration) dentro do resources que é por padrão onde Flyway verifica.
Após os diretórios criados, os scripts devem ser criados nessa devida pasta como demonstrado abaixo.
/db/migration/V1__script.sql
CREATE TABLE tb_empresa (
id_empresa NUMBER PRIMARY KEY,
sq_versaoregistro INTEGER DEFAULT 0 NOT NULL,
nr_cnpj VARCHAR(14) NOT NULL,
nm_fantasia VARCHAR(100) NOT NULL,
nm_razaosocial VARCHAR(100) NOT NULL,
sn_ativo BOOLEAN NOT NULL,
CONSTRAINT PK_EMPRESA PRIMARY KEY (nr_cnpj)
);
/db/migration/V2__script.sql
CREATE TABLE tb_usuario (
id_usuario NUMBER PRIMARY KEY,
sq_versaoregistro INTEGER DEFAULT 0 NOT NULL,
nm_login VARCHAR(14) NOT NULL,
cn_senha VARCHAR(255) NOT NULL,
sn_ativo CHAR(1) NOT NULL,
CONSTRAINT PK_USUARIO PRIMARY KEY (id_usuario)
);
/db/migration/V3__script.sql
1 | INSERT INTO tb_empresa(nr_cnpj, nm_fantasia, nm_razaosocial, sn_ativo) VALUES ('03025433000190', 'Empresa', 'Empresa LTDA', true); |
Criados os scripts agora é preciso configurar o Flyway para utilizar a estrutura de versionamento.
A configuração consiste em basicamente criar uma instância do flyway, passando o parâmetro locations com o path da pasta, demonstrado no trecho abaixo.
Flyway
.configure()
.cleanDisabled(true)
.dataSource(dataSourceStructure)
.schemas("ADMFIS")
.table("TB_FLYWAYSTRUCTURE")
.outOfOrder(true)
.locations("db/migration")
.load()
.migrate();
Configuração com JAVAEE e JARCH
Como estratégia de execução dos scripts utilizei o método migrate, que compara a versão atual da base dados com os scripts versionados e executa os novos arquivos inseridos na estrutura, caso queiram conhecer mais afundo sobre essa estratégia segue o link da documentação.
No Java EE a chamada das configurações de Flyway serão chamadas dentro de um método de inicialização de um EJB no Startup da aplicação.
package br.com.dsfnet.admfis.web.flyway;
import org.flywaydb.core.Flyway;
import javax.annotation.PostConstruct;
import javax.annotation.Resource;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.sql.DataSource;
@Startup
@Singleton
@TransactionManagement(TransactionManagementType.BEAN)
public class FlywaySetup {
@Resource(lookup = "java:/ds/flyway")
private DataSource dataSourceStructure;
@PostConstruct
public void init() {
Flyway
.configure()
.cleanDisabled(true)
.dataSource(dataSourceStructure)
.schemas("ADMFIS")
.table("TB_FLYWAYSTRUCTURE")
.outOfOrder(true)
.locations("db/migration")
.load()
.migrate();
}
}A classe FlywaySetup é anotada com @Startup para ser executada na inicialização da aplicação e a criação das configurações do Flyway devem ser executadas no PostConstruct para que o dataSouce esteja injetado nesse momento.
Também foi utilizada a anotação @TransactionManagement do tipo Bean porque se trata de alterações na base de dados, pois o Flyway trabalha com transações (em algumas bancos, consulte a documentação) para executar os scripts, pois, caso haja falhas na execução é precisa realizar o rollback das alterações.
Utilizei um datasource onde o usuário tem permissão de alterar estrutura do banco de dados.
Agora falta somente adicionar a dependência da API do Flyway no pom.xml:
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<version>7.5.0</version>
</dependency>
Essa estratégia de regularização de banco de dados é uma ótima opção pois evita que um publicação seja feito em algum ambiente sem que o mesmo não tenha sido regularizado seu banco de dados.
Até a próxima,
