BD – Blog do Camilo

Automatizando seu DB com FlyWay Plugin – MySql

Olá Pessoal,

No post de hoje vou mostrar para vocês como podemos automatizar a criação de um banco de dados usando o plugin flyway. Aqui na ITS temos usado o plugin para aumentar a produtividade e sempre manter a integridade dos ambientes.

Lets go…

O problema

Há várias ferramentas e formas de automatizar a criação das tabelas do banco com cenários já prontos ou até vazios. Aqui na ITS, para os projetos Java temos usado o flyway, apesar de que testamos outras como o DBMaintain, mas optamos pelo plugin flyway, já que em termos de resultado final era semelhante ao dbmaintain, porém a curva de aprendizado e configuração era mais rápida. Para projetos Ruby, estamos vendo outra solução.

O problema que tínhamos aqui era a criação da base de dados para cada ambiente, desde local até ambiente de INT, DEV e PROD. A modelagem do banco pode mudar (e certamente vai) e quando isso acontece, o problema está feito. Como atualizar cada ambiente rapidamente?

Opção 1

Criar um dump do banco e rodar o .sql em cada ambiente manualmente.

Opção 2

Automatizar esse processo de update.

Nesse post vamos nos limitar apenas em como gerar a base de dados rapidamente. Em outro post veremos como atualizar outros ambientes através de uma ferramenta de build continuous como o Jenkins.

A opção 1 funciona, mas não é a ideal, pois é preciso logar em cada ambiente e rodar o .sql. Isso consome tempo e é chato de fazer, ninguém gosta de fazer esse trabalho repetitivo. E se o banco durante o dia mudar 3 ou 4 vezes? Quantas vezes você vai executar a opção 1? Se você tem 3 ambientes para atualizar será preciso fazer isso 3 vezes a cada mudança. Péssimo, não?

A opção 2

Você pode automatizar. Há ferramentas que ajudam a fazer isso usando um Servidor de Build como o Jenkins ou até como plugin maven. Já usei o dbmaintain, mas analisando outras opções encontrei o flyway, até porque o desenvolvedor pode rodar o plugin local e se tiver o banco de dados rodando em segundos ele tem o ambiente local atualizado.

Configurando o FlyWay via Maven

Antes de tudo você precisa ter um arquivo .sql que irá criar as tabelas e ele deve estar nessa estrutura: src/main/resources/db/migration

E o nome do arquivo tem que ser V1__QUALQUERNOME.sql

São 2 underscore. Se seu banco mudou você precisa ter um V2 e assim por diante. O flyway faz um tracking disso e salva em uma tabela schema_version. Se você tem mais de um ambiente, sugiro dar uma lida nesse post:

http://lwandersonmusings.blogspot.com/2012/07/using-maven-to-integrate-flyway.html

Vamos ver na prática um simples exemplo. Vou considerar que você já tem um projeto Maven

Step 1

Abra o pom e adicione:

<plugin>

                           <groupId>com.googlecode.flyway</groupId>

                           <artifactId>flyway-maven-plugin</artifactId>

                           <version>2.2.1</version>

                           <configuration>

                                  <url>jdbc:mysql://localhost:3306/seu_database</url>

                                  <user>camilo </user>

                                  <password>2014</password>

                           </configuration>

                           <dependencies>

                                  <dependency>

                                        <groupId>mysql</groupId>

                                  <artifactId>mysql-connector-java</artifactId>

                                        <version>5.1.25</version>

                                  </dependency>

                           </dependencies>

                    </plugin>

Step 2

Garanta que o banco foi inicializado.

Step 3

Garanta que o database exista, caso contrário o flyway não vai conseguir conectar.

Step 4

via command line (se preferir pode usar o Eclipse) digite o seguinte comando:

Step 5

Veja o resultado:

Observe que as tabelas foram criadas. Tive que ocultar os nomes das tabelas.

Simples não?

Alguns comandos básicos

mvn flyway:clean

Limpar o Database, ou seja, todas tables são apagadas.

mvn flyway:info

Mostra quando o último script foi rodado e o status.

mvn flyway:migrate

Faz a migração, ou melhor, executa o .sql em si.

Note: Você pode usar o recurso de profiles e ter diferentes execuções para o flyway.

O flyway tem se mostrado um plugin muito bom no dia a dia e atendendo aos requisitos que precisamos, sem falar que tem uma boa documentação e os posts no blog deles tem sido bem mão na massa.

Abraços, see ya!!

DBUnit com HSQLDB + Hibernate + maven

Olá pessoal!

No post de hoje vamos ver como executar nossos unit tests usando o DBunit com HSQLDB em memória, tendo o Hibernate como framework de persistencia e usando o maven. por que isso tudo? Eu passei por uns problemas chatos de configuração que normalmente não temos quando fazemos testes de cada um desses recursos separados, mas, quando tive que colocar tudo na mesma panela, surgiram uns problemas mais chatos para nós, desenvolvedores, estou falando daquelas exceções de não achar o arquivo, exceções genéricas dos frameworks, que nos faz ficar horas e horas googlando, etc.

lets go..

O que vou considerar?

Que você já conhece Hibernate e conhece o DBunit, porém agora pretende rodar seus testes em um projeto do tipo maven e que você tem dois arquivos hibernate.cfg.xml, um para os testes e outro para a aplicação em si.

O problema

Tudo começou quando, ao executar meus testes, simplesmente recebi aquela velha mensagem: cannot open JDBC Connection. Eu disse “como assim? O hibernate.cfg.xml está lá”. Daí comecei a investigar. Um ponto eu já sabia e publiquei aqui nesse troubleshooting: o maven procura o hibernate.cfg.xml em src/main/resources. E para os testes? Ele procura em src/test/resources. Até parece lógico, mas errei aqui e não coloquei meu arquivo de hibernate.cfg.xml de teste nesse local. Porém, veio outro problema: eu tinha renomeado meu arquivo hibernate.cfg.xml para hibernateTest.cfg.xml. Por que? Simplesmente queria ter essa diferença. E deixava assim a configuração nos meus testes:

protected IDatabaseConnection getConnection() throws Exception {

conn = new DatabaseConnection(new Configuration().configure(“hibernateTest.cfg.xml”)

.buildSettings().getConnectionProvider().getConnection());

return conn;

}

Simplesmente recebia:

Dai o que fiz?

Mudei o arquivo para hibernate.cfg.xml e rodei a aplicação e o resultado:

Isso me custou umas 3hrs do meu dia. Infelizmente não fui pesquisar porque com o nome diferente do hibernate o maven não encontrava o arquivo, somente com o nome default.

O arquivo do DBunitTest é o mesmo que vimos nos outros post da série, a única diferença é que temos um projeto do tipo “simple maven project”.

Hibernate.cfg.xml para o HSQLDB

<session-factory>

<property name=”hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=”hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=”hibernate.connection.username”>sa</property>

<property name=”hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=”hibernate.show_sql”>true</property>

<property name=”hibernate.hbm2ddl.auto”>create-drop</property>

<mapping class=”com.camilolopes.qa.model.dao.bean.Account”/>

</session-factory>

Configuração do pom.xml Adicione as dependencias abaixo:

<dependency>

<groupId>hsqldb</groupId>

<artifactId>hsqldb</artifactId>

<version>1.8.0.10</version>

</dependency>

<dependency>

<groupId>javassist</groupId>

<artifactId>javassist</artifactId>

<version>3.12.1.GA</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.hibernate</groupId>

<artifactId>hibernate-core</artifactId>

<version>3.6.10.Final</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.dbunit</groupId>

<artifactId>dbunit</artifactId>

<version>2.4.8</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

Crie um bean e um teste para persistir o objeto:

Bean

@Entity

@Table(name=”account”)

public class Account {

@Id

@GeneratedValue

@Column(name=”ID”)

private Long id;

@Column(length=20,name=”TYPE”)

private String type;

}

Test

A classe de test deverá estar assim, e omitir o que não mudou do outro arquivo, como a conexão e o load do .xml.

public DBUnitTest() {

try {

session = getSessionFactory().openSession();

getDataSet();

} catch (Exception e) {

e.getMessage();

}

}

public static SessionFactory getSessionFactory() {

sessionFactory = new Configuration().configure().buildSessionFactory();

return sessionFactory;

}

@Test

public void testSave(){

session.beginTransaction();

Account account = new Account();

account.setType(“USER”);

session.save(account);

}

Enfim, é isso ai. Caso precise rodar seus unit tests com maven + hibernate + hsqldb, sem ter dor de cabeça com arquivo de configuração, essa foi a solução que encontrei.

Abracos, see ya!!

Testes com DBUnit & HSQLDB

Olá Pessoal,

Hoje veremos como deixar nossos testes com DBUnit usando o HSQLDB. O motivo que queremos rodar o banco em memoria, ou seja, evitarmos de termos que ter o banco rodando para executar os testes, o mesmo será iniciado somente quando os testes forem executado. Como você pode observar no último post, sempre temos que ter o MySql rodando para que as coisas funcionem e ter essa dependência no dia-dia enquano estamos desenvolvendo é ruim, pois vamos exigir que cada desenvolvedor tenha que ter o MySql instalado na maquina etc. Não queremos isso. Queremos que ele faça o checkout do código e possa rodar.

Lets go…

Starting…

Como já falado no post anterior vimos como automatizar nossos testes usando DBUnit + Mysql, porém o que vimos de ruim é o fato de ter sempre o serviço do MySql rodando. E se quisermos rodar isso em memoria, como fazer? O HSQLDB nos dá uma mãozinha para rodar nossos testes com o HSQLDB, é muito simples, basta alterarmos o hibernate.cfg.xml e ter o .jar do HSQLDB adicionado ao projeto.

Vou considerar que você tem o projeto anterior, mas caso não tenha, siga os passos do primeiro post e mude apenas o arquivo do hibernate.cfg.xml.

1. O primeiro passo é criar o arquivo hibernate.cfg.xml com as configurações do banco onde os testes serão executados.

<hibernate-configuration>

<session-factory>

<property name=“hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=“hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=“hibernate.connection.username”>sa</property>

<property name=“hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=“hibernate.show_sql”>true</property>

</session-factory>

</hibernate-configuration>

Pronto, feito isso basta rodar os testes novamente e done. O resultado é Green . Simples, não? Assim tiramos a dependência do MySql.

Vou ficando por aqui… Essa foi fácil.

Abraços, see ya!!

Throubleshooting MySql Case Sensitive Criteria Hibernate

Olá Pessoal,

Mais um thoubletshooting, e dessa vez é com o Mysql. É aquela velha frase “vivendo e aprendendo”. No dia a dia trabalho com outros bancos de dados, mas nos meus projetos house-made gosto do mysql.

Um dia desses estava desenvolvendo e um dos requisitos era considerar o case-sensitive. Dai vou lá feliz da vida usando o Criteria do Hibernate com o MySql:

criteria.add(Restrictions.eq(“email”, email));

criteria.add(Restrictions.eq(“password”, password));

E o que acontece?

Simplesmente se tiver:

camilo@camilolopes.com com o password: 123cam

e

camilo@camilolopes.com com o password: 123CAM

Teremos dois registros no retorno.

Daí fui ver na documentação o motivo e achei isso:

http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html

Solução

Como podemos ver na documentação acima, o Mysql trata Varchar como case-insensitive. Daí ao criar a tabela devemos setar a flag Binary. Caso a tabela já exista, basta dar um alter table

ALTER TABLE `user` MODIFY COLUMN `EMAIL` VARCHAR(255) BINARY CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL;

Pronto. E resolvido.

Vou ficando por aqui.

See ya!!!

Sincronizando dados WorkBench para MySQL

olá Pessoal,

Neste post vou mostrar como sincronizar dados do WorkBench com o MySQL, assim as alterações realizadas no Workbench, causará impacto direto no banco, lembrando que esse recurso não fica de forma default por medida de segurança. O post será bem pequeno e objetivo. Vou considerar que você já tem o workbench instalado e uma base de dados no MySQL. Apesar de para uns parecer um posts para usuários básicos, mas fazer modelagem de dados é algo que acontece com uma certa frequencia à depender do projeto. E saber usar uma ferramenta de modelagem não é nada mal.

lets go…

Post Relacionado

Modelagem de dados WorkBench MySql

Starting…

Mas, você deve está se perguntando e se eu alterar as tabelas no WorkBench estas alterações serão refletidas automaticamente no Banco de Dados? A resposta é não. Para que isso seja possível, precisamos informar ao WorkBench que ele deve passar as alterações para o BD.

O processo é bem semelhante ao que fizemos para importar do MySQL para o WorkBench. Basta ir em DataBase ==> Synchronize Model.

Siga as instruções da ferramenta, porém fique atento apenas para a penúltima tela, pois deve ser informado quais tabelas serão atualizadas e certifique-se de ignore aquelas que não sofreram alterações. Do contrário tudo que estiver no BD, será substituído e perdido. Veja, como ficou a nossa:

Espero que tenham gostado do post, vou ficando por aqui, e até próxima.

See ya! Abraços,