Banco de Dados Evolutivo – Parte 14

Esse é o último post da série Banco de Dados Evolutivo. Nessa etapa você irá migrar a base de dados de Produção para a versão 2 e aprenderá como executar o comando ROLLBACK <versão>.


Depois de ter desnormalizado a base de dados de Homologação da Adventure Works (veja o a Parte 13 do conjunto de posts da série) será necessário adicionar à tabela databasechangelog a nova versão do database.

Para isso, assim como já fora feito na versão 1.0 (veja a Parte 12) , será necessário criar um arquivo XML de nome changelog_2.xml que atribuirá à nova modificação de sistema a versão 2.0 – use o código da Listagem 1.

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog 
		http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext 
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<changeSet author="arthur" id="tagDatabase-versao_2.0">
    <tagDatabase tag="versao_2.0"/>
</changeSet>

</databaseChangeLog>

Listagem 1. Comando usado para criação do arquivo changelog_2.xml que adicionará à tabela databasechangeset a versão 2 do sistema da Adventure Works.

Altere também o arquivo master_2.0.xml para que seja possível a execução da nova refatoração através do código da Listagem 2.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog 
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext 
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_2.0/changelog_1.xml" />
<include file="C:/changelog/versao_2.0/changelog_2.xml" />

</databaseChangeLog> 

Listagem 2. Comando usado dentro do arquivo XML master_2.0.xml.

Como você já deve estar familiarizado, abra o cmd e, a partir da pasta raiz de sistema, execute o update na base de homologação através do Liquibase usando o código da Listagem 3.

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

Listagem 3. Comando usado no cmd para execução do comando UPDATE através do Liquibase em ambiente de Homologação.

Caso seja executado um SELECT na tabela de controle databasechangelog, será possível observar que a base de Homologação já se encontra em sua segunda versão conforme a Figura 1.

Figura 1. Resultado do SELECT executado na tabela databasechangelog após a adição da versão 2.
Figura 1. Retorno do SELECT na tabela databasechangelog após adição da versão 2.

Atualizando a Base de Dados de Produção – Versão 2

Nesse momento, depois de testada a ultima alteração em ambiente de homologação, será necessário atualizar a base de Produção para a ultima versão desenvolvida. Para isso, utilize o comando da Listagem 4.

java -jar C:\liquibase-3.0.8-bin\liquibase.jar --defaultsFile=C:\liquibase-3.0.8-bin\liquibaseProd.properties update

Listagem 4. Comando usado no cmd para execução do comando UPDATE através do Liquibase em ambiente de Produção.

Caso seja executado um SELECT na tabela databasechangelog em ambiente de Produção você verá que, assim como em Homologação, o sistema encontra-se na Versão 2.

O Comando Rollback <versão>

Nesse momento suponha o seguinte: Por algum motivo, será necessário que o sistema volte a ser normalizado contendo novamente os dados de tipo de telefone na tabela Person.PhoneNumberType. Dessa forma será necessário que voltemos o Banco para a Versão anterior, a versão 1, logo, esta contêm a estrutura DDL e DML anterior do banco.

Para que isso seja possível precisaremos executar um comando muito simples. Passaremos os parâmetros de conexão do Banco de Produção seguido do comando rollback <versao>.

O Liquibase irá até a tabela databasechangelog e verá quais as refatorações que não estão contidas na versão fornecida como parâmetro e executará o Rollback de todas elas. Porém é necessário lembrar do que foi mencionado na Parte 13 do conjunto de posts. Se a refatoração usada não possuir Auto Rollback, é preciso que você adicione a tag <rollback> … </rollback> e crie a refatoriação contrária. Caso contrário, não será possível desfazer o que está feito na versão atual.

Execute o comando da Listagem 5 para execução do Rollback <versao>.

java -jar C:/liquibase-3.0.8-bin/liquibase.jar --defaultsFile=C:/liquibase-3.0.8-bin/liquibaseProd.properties rollback versao_1.0

Listagem 5. Comando usado no cmd para execução do comando ROLLBACK <versão>. Através é possível retroceder até uma versão anterior desejada.

Conforme já vimos na primeira refatoração que executamos (veja a Parte 7 do conjunto de posts), é necessário que o arquivo XML que contenha a refatoração desfeita seja retirado do arquivo pai da versão (nesse caso o arquivo master_2.0.xml). Caso contrário a refatoração será reexecutada quando uma nova mudança for inserida.


Conclusão

O Liquibase é uma poderosa ferramenta de versionamento de Banco de Dados. Ela não se resume somente a isso que foi exposto nessa série de 14 posts. Esse foi somente um simples overview do que é possível fazer através dela (para mais informações consulte a documentação oficial da ferramenta).

Adaptando as técnicas citadas nos Partes 01, 02, 03 e 04 ao seu negócio e usando corretamente o Liquibase como fora ensinado da etapa 05 à 14 dos posts será possível gerenciar o versionamento de qualquer banco de dados, em qualquer ambiente, facilitando, dessa forma, o controle de versão de seu sistema como um todo.

Banco de Dados Evolutivo – Parte 13

Nesse post da série Banco de Dados Evolutivo você aprenderá a criar o XML com a bundled change SQL para executar comandos mais complexos em sua base de dados através da ferramenta de versionamento de banco de dados Liquibase.


Agora que você já está familiarizado com os comandos e com o funcionamento do Liquibase irá finalmente executar uma mudança significativa na estrutura e nos dados do nosso sistema de vendas da Adventure Works.

Você irá desnormalizar a base de dados passando a guardar os dados de tipo de telefone da tabela Person.PhoneNumberType dentro da tabela Person.PersonPhone. Para isso, precisaremos remodelar a base de dados. Veja na Figura 1 o modelo MER atual da base AdventureWorks_Homolog.

Figura 1. Modelo MER atual da base AdventureWorks_Homolog.
Figura 1. Modelo MER atual da base AdventureWorks_Homolog.

Agora acompanhe na Figura 2 como ela ficará após a alteração.

Figura 2. Modelo MER da base de dados AdventureWorks_Homolog após a alteração.
Figura 2. Modelo MER da base de dados AdventureWorks_Homolog após a alteração.

O Liquibase não possui uma Bundled Change para executar uma modificação tão complexa, porém, disponibiliza uma refatoração de nome SQL para que isso seja possível (como fora dito anteriormente na Parte 9 do conjunto de posts). Essa mudança permite que qualquer comando SQL – seja a nivel de DDL, DML ou DCL – seja executado através do Liquibase.

Usaremos o código da Listagem 1 dentro do arquivo XML de nome changelog_1.xml que deverá ser salvo na pasta C:\changelog\versao_2.0. Você dará esse nome para o arquivo XML porque se trata da primeira refatoração da Versão 2 do sistema.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<changeSet author="arthur" id="exclui tabela Person.PhoneNumberType">
<sql> 	

-- Adiciona a Coluna PhoneNumberType à tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
ADD PhoneNumberType VARCHAR(25)
GO

-- Guarda os dados de tipo de telefone na tabela Person.PersonPhone
UPDATE Person.PersonPhone
SET PhoneNumberType = (	SELECT Name
			FROM Person.PhoneNumberType
			WHERE Person.PhoneNumberType.PhoneNumberTypeID = Person.PersonPhone.PhoneNumberTypeID)
GO

-- Exclui a Primary Key da tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
DROP CONSTRAINT PK_PersonPhone_BusinessEntityID_PhoneNumber_PhoneNumberTypeID
GO 

-- Exclui a Foreign Key da tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
DROP CONSTRAINT FK_PersonPhone_PhoneNumberType_PhoneNumberTypeID
GO

-- Exclui a coluna PhoneNumberTypeID da tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
DROP COLUMN PhoneNumberTypeID
GO 

-- Exclui a tabela Person.PhoneNumberType
DROP TABLE Person.PhoneNumberType
GO	

</sql>
<rollback>   

-- Cria a tabela Person.PhoneNumberType
CREATE TABLE Person.PhoneNumberType (
	PhoneNumberTypeID INT PRIMARY KEY IDENTITY NOT NULL,
	Name VARCHAR (25) NOT NULL,
	ModifiedDate DATETIME
	)
GO

-- Insere os dados de tipo de telefone na tabela Person.PhoneNumberType
INSERT INTO Person.PhoneNumberType
SELECT DISTINCT	PhoneNumberType,
		GETDATE()
FROM Person.PersonPhone
GO

-- Adiciona a coluna PhoneNumberTypeID na tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
ADD PhoneNumberTypeID INT
GO

-- Adiciona a chave da tabela Person.PhoneNumberType na tabela Person.PersonPhone
UPDATE Person.PersonPhone
SET PhoneNumberTypeID = (	SELECT PhoneNumberTypeID
			FROM Person.PhoneNumberType
			WHERE Person.PhoneNumberType.Name = Person.PersonPhone.PhoneNumberType)
GO

-- Torna a coluna PhoneNumberTypeID NOT NULL
ALTER TABLE Person.PersonPhone
ALTER COLUMN PhoneNumberTypeID INT NOT NULL
GO

-- Adiciona a Foreign Key na tabela PersonPhone
ALTER TABLE Person.PersonPhone
WITH CHECK ADD CONSTRAINT FK_PersonPhone_PhoneNumberType_PhoneNumberTypeID
FOREIGN KEY(PhoneNumberTypeID)
REFERENCES Person.PhoneNumberType (PhoneNumberTypeID)
GO

-- Habilita a Constraint FK_PersonPhone_PhoneNumberType_PhoneNumberTypeID
ALTER TABLE Person.PersonPhone
CHECK CONSTRAINT FK_PersonPhone_PhoneNumberType_PhoneNumberTypeID
GO

-- Exclui a coluna que guarda o tipo de telefone da tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
DROP COLUMN PhoneNumberType
GO

-- Adiciona a Primary Key na tabela Person.PersonPhone
ALTER TABLE Person.PersonPhone
ADD CONSTRAINT PK_PersonPhone_BusinessEntityID_PhoneNumber_PhoneNumberTypeID PRIMARY KEY CLUSTERED
(
	BusinessEntityID ASC,
	PhoneNumber ASC,
	PhoneNumberTypeID ASC
)WITH (	PAD_INDEX = OFF,
		STATISTICS_NORECOMPUTE = OFF,
		SORT_IN_TEMPDB = OFF,
		IGNORE_DUP_KEY = OFF,
		ONLINE = OFF,
		ALLOW_ROW_LOCKS = ON,
		ALLOW_PAGE_LOCKS = ON)
GO

</rollback>

</changeSet>
</databaseChangeLog>

Listagem 1. Comando usado para criação do arquivo XML changelog_1.xml. Observe a utilização da tag ROLLBACK. Ela é responsável por desfazer a alteração executada na bundled change SQL caso seja necessário.

Agora uma dica: é aconselhável que a tag <rollback> … </rollback> seja incluída em todas as refatorações que não possuam rollback automático (para mais informações sobre as refatorações que possuem rollback automático ou não, acesse a pagina principal de Bundled Changes no site oficial do Liquibase e selecione a refatoração desejada. Na parte Database Support, na coluna Auto Rollback é possível saber se aquela change possui ou não auto rollback para cada banco de dados).

Após concluída a criação do arquivo changelog_1.xml e de colocado na pasta versao_2.0, você precisará criar o arquivo master_2.0.xml e colocá-lo na pasta de mesmo nome dentro do diretório changelog. Use o comando da Listagem 2.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_2.0/changelog_1.xml" />

</databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo XML master_2.0.xml.

Depois disso, altere o arquivo master.xml conforme a Listagem 3 para adicionar a execução do arquivo master_2.0.xml.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_1.0/master_1.0.xml" />
<include file="C:/changelog/versao_2.0/master_2.0.xml" />

</databaseChangeLog>

Listagem 3. Comando usado dentro do arquivo master.xml para adicionar a nova tag de include para o arquivo master_2.0.xml.

Agora você já sabe o que fazer. Basta executar o comando da Listagem 4 no cmd do windows (a partir diretório raiz do sistema). O Liquibase irá fazer o que chamamos de Migrate. Ele trabalhará a nível de DDL e DML para retirar os dados de tipo de telefone da tabela Person.PhoneNumberType e armazená-los na nova coluna PhoneNumberType na tabela Person.PersonPhone. Criará as foreign keys e constraints e depois excluirá a tabela Person.PhoneNumberType e também a coluna PhoneNumberTypeID da tabela Person.PersonPhone.

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

Listagem 4. Comando usado no cmd para execução do comando UPDATE através do Liquibase em ambiente de Homologação.

Agora que o comando foi executado, faça um SELECT na tabela Person.PersonPhone da nossa base de homologação (conforme na Figura 3) e veja que a coluna que possuía os IDs dos tipos de telefone não mais existe. Ao invés disso temos a nova coluna de nome PhoneNumberType. Caso navegue nos objetos de banco poderá também ver que não mais existe a tabela Person.PhoneNumberType.

Figura 3. SELECT executado na tabela Person.PersonPhone após a refatoração.
Figura 3. SELECT executado na tabela Person.PersonPhone após a refatoração.

No próximo post da série você irá migrar a base de dados de Produção para a segunda versão do sistema e aprenderá a executar o comando ROLLBACK <versao>.

Banco de Dados Evolutivo – Parte 12

Nesse post da série Banco de Dados Evolutivo, você aprenderá como versionar a sua base de dados para dessa forma conseguir evoluir o seu database de Produção por versões (não como tem feito em Homologação – por changesets). Paralelo a isso, aprenderá também como executar o comando DIFF database através da ferramenta de versionamento de banco de dados Liquibase.


no post anterior (Parte 11) você finalizou a primeira versão do banco de dados da Adventure Works.

Para que seja possível uma fácil identificação das refatorações correspondentes a cada versão, dentro da tabela de controle databasechangelog existe uma coluna chamada tag. Dentro dessa coluna você deverá assinalar no registro da última alteração realizada a que versão o conjunto de mudanças pertence.

Podemos adicionar a tag de versão de três formas:

  1. Fazendo um UPDATE manual na tabela databasechangelog;
  2. Usando o comando tag ‘<Nome da Versão>’ via linha de comando (veja mais sobre esse comando dentre outros aqui);
  3. Usar um arquivo XML com uma refatoração de denominada tagDatabase;

A forma que irei demonstrar neste post será através do arquivo XML. Dessa forma, reduzimos ao máximo a intervenção humana ao nosso fluxo alterações.

Utilize o comando da Listagem 1 para criação do XML com a refatoração de adição da tag com a versão da base de dados denominada changelog_5.xml.

 <databaseChangeLog
         xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
         xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
		 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
         http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <changeSet author="arthur" id="tagDatabase-versao_1.0">
     <tagDatabase tag="versao_1.0"/>
 </changeSet>

 </databaseChangeLog>
 

Listagem 1. Comando usado para criação do arquivo changelog_5.xml que adicionará à tabela databasechangeset a versão do conjunto de alterações.

Utilize o comando da Listagem 2 dentro do arquivo master_1.0.xml (como você já deve estar se habituando a fazer).

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_1.0/changelog_2.xml" />
<include file="C:/changelog/versao_1.0/changelog_3.xml" />
<include file="C:/changelog/versao_1.0/changelog_4.xml" />
<include file="C:/changelog/versao_1.0/changelog_5.xml" />

</databaseChangeLog>
 

Listagem 2. Comando usado dentro do arquivo master_1.0.xml para que seja possível a adição da versão da base de dados de homologação.

Depois de de você ter feito todas essas alterações em homologação está na hora do sistema de produção da Adventure Works receber as modificações e passar a usá-las. Para que seja possível usar a ferramenta de versionamento de banco de dados Liquibase no ambiente de produção é necessário que, assim como fizemos um arquivo liquibaseHomolog.properties para o banco de homologação, façamos um outro chamado liquibaseProd.properties com todas as informações para que o Liquibase possa se conectar à base de produção. Segue o código de criação na Listagem 3.

driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 
classpath: C:/liquibase-3.0.8-bin/sqljdbc4.jar 
url: jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Prod 
username: 
password: 
changeLogFile: C:/changelog/master.xml

Listagem 3. Comando usado para criar o arquivo liquibaseProd.properties. Salve-o no diretório C:\liquibase-3.0.8-bin\ junto ao outro arquivo properties para a base de Homologação.

Agora que você possui livre acesso ao banco de dados de Produção através do Liquibase, veja abaixo as duas formas de commitar as alterações executadas em ambiente de Homologação no ambiente de Produção.

O Comando DIFF Database

O comando DIFF da ferramento Liquibase consiste em analisar a estrutura DDL de dois bancos de dados e identificar as diferenças de entre ambas as bases (Veja a Parte 4 do conjunto de posts).

Para que seja possível usar e executar um DIFF entre duas bases será preciso tanto especificar os dados da base de referência (base a qual o Liquibase usará de parâmetro para gerar o arquivo XML de refatorações) quanto o diretório e arquivo onde guardaremos essas alterações. Segue o comando que comparará as bases na Listagem 4.

java -jar C:/liquibase-3.0.8-bin/liquibase.jar --driver=com.microsoft.sqlserver.jdbc.SQLServerDriver --classpath=C:/liquibase-3.0.8-bin/sqljdbc4.jar --url=jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Prod --defaultSchemaName=Person --username= --password= --changeLogFile=C:/changelog/diff_Prod-Homolog.xml diffChangeLog --referenceUrl=jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Homolog --referenceUsername= --referencePassword=

Listagem 4. Comando usado para gerar um DIFF entre as bases de Produção e Homologação da Adventure Works.

Observe que você não usará ainda o arquivo liquibaseProd.properties, logo, dentro dele passamos como parâmetro o arquivo master.xml. Caso você apontasse o arquivo de configuração, o Liquibase salvaria o XML de refatorações dentro do arquivo master.xml.

Fora usado o parâmetro –defaultSchemaName para dizer ao Liquibase que schema da base de dados ele precisa verificar. Se você não o usasse, a ferramenta iria buscar as alterações no Schema Default do Database (nesse caso, o schema dbo).

Observe também que o comando usado pra o DIFF entre as bases é o diffChangeLog.

Se aberto o arquivo gerado, teremos o código conforme da Listagem 5.

 <databaseChangeLog
         xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
         xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
		 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
         http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

    <changeSet author="arthurluz (generated)" id="1437256942611-1">
        <addColumn tableName="Person">
            <column name="Cpf" type="varchar(11)">
                <constraints nullable="false"/>
            </column>
        </addColumn>
    </changeSet>

    <changeSet author="arthurluz (generated)" id="1437256942611-2">
        <addColumn tableName="Person">
            <column name="FullName" type="varchar(255)"/>
        </addColumn>
    </changeSet>

    <changeSet author="arthurluz (generated)" id="1437256942611-3">
        <dropColumn columnName="FirstName" tableName="Person"/>
    </changeSet>

    <changeSet author="arthurluz (generated)" id="1437256942611-4">
        <dropColumn columnName="LastName" tableName="Person"/>
    </changeSet>

</databaseChangeLog>

Figura 7. Comando do arquivo diff_Prod-Homolog.xml gerado através do comando diffChangeLog.

Se lido e verificado com bastante atenção o arquivo XML que foi gerado através do comando diffChangeLog será possível observar um grande problema. Ele não entende o merge columns que fora feito. Ao contrario, está solicitando a exclusão das colunas FirstName e LastName (claro, se o fizer estará excluido os dados também) e adicionando a coluna FullName.

Existe uma falha fundamental com o comando DIFF. Apesar de fazer um bom trabalho mostrando as diferenças estruturais, ele não entende a semântica das mudanças.

Por exemplo, se você renomear uma coluna de “nome” para “descricao”, o comando diff irá mostrar que há uma coluna “nome” que precisa ser eliminada e uma coluna “descricao” precisa ser adicionada. Se você seguir esta sugestão, você terá uma base de dados correta a nível de DDL, mas você irá perder todos os valiosos dados.

Por esse motivo, o aconselhamento é que o comando DIFF seja usado muito pouco e com muito cuidado. Veremos a seguir a outra maneira (a forma mais indicada) para commitar em produção as alterações que já foram executadas em homologação.

Gravando em Produção as primeiras refatorações – Continuação

De uma forma bem simples use o comando da Listagem 6 para executar em Produção todas as refatorações que foram criadas, executadas e testadas em ambiente de homologação.

java -jar C:\liquibase-3.0.8-bin\liquibase.jar --defaultsFile=C:\liquibase-3.0.8-bin\liquibaseProd.properties update

Listagem 6. Comando usado no cmd para execução do comando UPDATE através do Liquibase em ambiente de Produção.

Observe que o comando criou na base de dados de Produção da Adventure Works as tabelas de controle databasechangelog e databasechangeloglock.

Caso seja feito um SELECT na tabela databasechangelog em ambiente de Produção será possível observar que todas as refatorações que foram estão em Homologação agora também fazem parte do ambiente de Produção conforme a Figura 1.

Captura de Tela 2015-07-18 às 18.57.08
Figura 1. retorno do SELECT executado na tabela de controle databasechangelog na base de Produção.

No próximo post da série Banco de Dados Evolutivo veremos como executar modificações maiores e mais robustas através da bundled change SQL.

Banco de Dados Evolutivo – Parte 11

Nesse post da série Banco de Dados Evolutivo você aprenderá a executar a bundled change mergeColumn, bem como a execução do SQL Output através do comando updateSQL que é responsável por transformar as refatorações criadas em XML para comandos SQL (veja mais sobre cada um dos comandos na Parte 4 da série).


Você fará nesse momento do seu aprendizado algo um pouco mais complicado. Temos na tabela Person.Person duas colunas contendo o primeiro e último nome das pessoas que possuem alguma ligação com a Adventure Works. Essas colunas tem por nome: FirstName e LastName (tenho conhecimento da coluna MiddleName. Para fins de aprendizado esqueça essa coluna e trabalhe como se o nome das pessoas da Adventure Works fosse formado somente pelo seu primeiro e ultimo nome).

Você terá agora a missão de unir os dados dessas duas colunas em uma única coluna denominada FullName. Para que seja possível executar essa modificação use a refatoração de nome mergeColumns. Ao executar o comando, as colunas FirstName e LastName serão excluídas, passando a existir somente a nova coluna FullName.

Como você ja deve ter percebido, para que isso seja possível será preciso criar mais um arquivo XML usando o código da Listagem 1. Esse arquivo terá por nome changelog_4.xml.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <changeSet author="arthur" id="mergeColumns-nome_sobrenome">
  		<mergeColumns column1Name="FirstName"
           	 column2Name="LastName"
            	finalColumnName="FullName"
            	finalColumnType="varchar(255)"
            	joinString=" "
                schemaName="Person"
            	tableName="Person"/>
 </changeSet>

 </databaseChangeLog>

Listagem 1. Comando usado dentro do arquivo changelog_4.xml para criar a coluna FullName na tabela Person.Person da base de dados AdventureWorks_Homolog e, por sua vez, excluir as colunas FirstName e LastName.

Você adicionará a tag de execução dessa nova alteração dentro do arquivo master_1.0.xml segundo a Listagem 2.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_1.0/changelog_2.xml" />
<include file="C:/changelog/versao_1.0/changelog_3.xml" />
<include file="C:/changelog/versao_1.0/changelog_4.xml" />

</databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo master_1.0.xml para incluir a execução da nova refatoração changelog_4.xml.

Agora, antes de executar a nova alteração na base de homologação você aprenderá um outro comando de extrema importância da ferramenta Liquibase. O SQL OUTPUT.

O comando SQL Output – updateSQL

         O comando SQL OUTPUT, como já foi dito na Parte 4 da série, é responsável por transformar os changesets em comandos SQL ANSI. Ele é executado através do código updateSQL. Dessa forma, é possível para o Administrador de Banco de Dados ou Administrador de Dados analisar de forma mais visual a alteração que está prestes a ser executada no database.

É muito importante saber que você precisa transformar o arquivo XML em SQL antes de executá-lo pois, depois de estar registrado dentro da tabela de controle databasechangelog, não será mais possível gerar o SQL do arquivo.

Para que seja possível visualizar a alteração em um documento SQL, basta que você utilize o comando da Listagem 3 no cmd (lembre-se sempre de executar os comandos Liquibase dentro da pasta raiz do sistema).

java -jar C:/liquibase-3.0.8-bin/liquibase.jar --driver=com.microsoft.sqlserver.jdbc.SQLServerDriver --classpath=C:\liquibase-3.0.8-bin\sqljdbc4.jar --url=jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Homolog --username=<usuario> --password=<senha> --changeLogFile=C:\changelog\versao_1.0\changelog_4.xml updateSQL > C:\changelog\versao_1.0\changelog_4.sql

Listagem 3. Comando usado para gerar o arquivo changelog_4.sql. Esse arquivo será salvo na pasta C:\changelog\versao_1.0.

Observe que não usamos o arquivo liquibaseHomolog.properties pois o mesmo guarda os dados do arquivo master.xml. Para gerar o arquivo SQL você precisa partir do arquivo XML que possui as informações de changesets.

Abra o arquivo SQL gerado e você o verá tal qual a Figura 1.

Captura de Tela 2015-07-15 às 03.43.35
Figura 1. Arquivo changelog_4.sql gerado com o comando updateSQL a partir do arquivo changelog_4.xml.

É possível executar o comando updateSQL em qualquer arquivo de refatoração XML antes de sua execução.

Bundled change mergeColumns – Continuação

Para que seja possível um melhor entendimento do comando mergeColumns criado no XML mais a cima vou explicar abaixo o significado de cada um dos atributos do arquivo:

  • Os atributos column1Name e column2Name nada mais são que a primeira e a segunda coluna a serem unidas.
  • Os atributos finalColumnName e finalColumnType servem para nomear a nova coluna que será gerada e determinar o seu tipo de dado respectivamente.
  • O atributo joinString serve para determinar o que você quer colocar (caso queira) entre os dados das duas colunas. No nosso caso, foi colocado um espaço em branco pois não queremos os que o nome e sobrenome do cliente se torne um só.
  • O atributo tableName nada mais é que o nome da tabela em que a alteração será executada.

Antes de você executar o comando update será preciso excluir o index IX_Person_LastName_FirstName_MiddleName das bases de dados AdventureWorks_Homolog e AdventureWorks_Prod através do código SQL da Listagem 4 (seria possível executar essa alteração em um changeset separado através da bundled change de nome dropIndex – saiba mais aqui. Mas a intenção aqui é que você aprenda a usabilidade da ferramenta, por isso, vamos direto ao ponto).

USE [AdventureWorks_Homolog]
GO

DROP INDEX [IX_Person_LastName_FirstName_MiddleName]
ON [Person].[Person]
GO
USE [AdventureWorks_Prod]
GO

DROP INDEX [IX_Person_LastName_FirstName_MiddleName]
ON [Person].[Person]
GO

Listagem 4. Comando usado para excluir o index IX_Person_LastName_FirstName_MiddleName das bases de Homologação e Produção para que seja possível continuar os testes com a ferramenta de versionamento Liquibase.

Agora, execute o comando da Listagem 5 para finalizar a alteração.

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

Listagem 5. Comando usado no cmd para execução do comando UPDATE através do Liquibase.

Execute um SELECT na tabela Person.Person terá um retorno conforme a Figura 2.

Captura de Tela 2015-07-15 às 04.02.32
Figura 2. Retorno da tabela Person.Person após adição da coluna FullName.

No próximo post da série você aprenderá a versionar a sua base de dados e a executar um outro delicado e importante comando da ferramenta de versionamento de banco de dados Liquibase, o DIFF database.

Banco de Dados Evolutivo – Parte 10

Nesse post da série Banco de Dados Evolutivo você aprenderá uma nova refatoração  (Bundled Changes). A AddNotNullConstraint


A nova coluna de nome Cpf que adiciona na nossa base AdventureWorks_Homolog através da Bundled Change addColumn (veja a Parte 9 da série) aceita NULL como valor de entrada. Porém, vamos supor que na nossa regra de negócios esse novo dado deverá ser obrigatório. Precisamos, dessa forma, adicionar a essa coluna uma constraint NOT NULL. Para isso, usaremos a refatoração de nome AddNotNullConstraint.

Criaremos agora um novo arquivo XML de nome changelog_3.xml contendo essa nova alteração DDL na nossa base de homologação. Para isso, use o código da Listagem 1.

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<changeSet author="arthur" id="add not null constraint - coluna Cpf">
     <addNotNullConstraint columnDataType="varchar(11)"
         columnName="Cpf"
		defaultNullValue="SR"
		schemaName="Person"
		tableName="Person"/>
</changeSet>

</databaseChangeLog>

Listagem 1. Comando usado dentro do arquivo changelog_3.xml para adicionar a constraint NOT NULL na coluna Cpf.

Após criado o XML adicionaremos a nova refatoração dentro do arquivo master_1.0.xml conforme a Listagem 2.

<databaseChangeLog
       xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
       xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
       http://www.liquibase.org/xml/ns/dbchangelog-ext
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

<include file="C:/changelog/versao_1.0/changelog_2.xml" />
<include file="C:/changelog/versao_1.0/changelog_3.xml" />

</databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo master_1.0.xml para adicionar a tag de include da refatoração contida no arquivo changelog_3.xml.

Agora execute o comando da Listagem 3 para realizar a refatoração na base de Homologação.

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

Listagem 3.Comando usado no cmd para execução do comando UPDATE através do Liquibase.

Se tudo foi executado corretamente você perceberá que agora nossa coluna Cpf não aceitará mais INSERTs de valores NULL e também que os campos que estavam nulos receberam um valor de entrada DEFAULT SR. Para verificarmos se realmente não é mais possível inserir nessa coluna registros com valor NULL, execute o INSERT da Listagem 4 na base de dados AdventureWorks_Homolog.

USE [AdventureWorks_Homolog]
GO

INSERT INTO [Person].[BusinessEntity]
           ([rowguid]
           ,[ModifiedDate])
     VALUES
           (NEWID(),
           GETDATE())
GO

INSERT INTO [Person].[Person]
           ([BusinessEntityID]
           ,[PersonType]
           ,[NameStyle]
           ,[Title]
           ,[FirstName]
           ,[MiddleName]
           ,[LastName]
           ,[Suffix]
           ,[EmailPromotion]
           ,[AdditionalContactInfo]
           ,[Demographics]
           ,[rowguid]
           ,[ModifiedDate]
           ,[Cpf])
     VALUES
           (20778,
           'IN',
			0,
           'Sr',
           'Arthur',
			NULL,
           'Luz',
           NULL,
			0,
			NULL,
			NULL,
           '3FBB4564-B55B-459A-A324-A9E0CD99D610',
           GETDATE(),
           NULL)
GO

Listagem 4. Comando utilizado para inserir na tabela Person.Person um novo registro para testarmos a modificação realizada. Para isso é necessário que seja inserido um novo registro primeiramente na tabela Person.BusinessEntity.

Ao executar o comando, o seguinte erro será apresentado:

Cannot insert the value NULL into column ‘Cpf’, table ‘AdventureWorks_Homolog.Person.Person’; column does not allow nulls. INSERT fails.

Captura de Tela 2015-07-10 às 21.36.41
Figura 1. SELECT na tabela Person.Person. Note também que, graças ao atributo DefaultNotNull adicionamos aos registros anteriores valor SR.

Se ao invés de usarmos o valor NULL na coluna Cpf do INSERT acima adicionarmos o valor ‘00000000000’ no INSERT da tabela Person.Person, obteremos o resultado conforme a Figura 1.

Vamos acompanhar também nossa tabela de controle de alterações, a databasechangelog. Execute o SELECT da Listagem 5 na nossa base de dados de Homologação. Dessa forma será possível ver as duas alterações executadas com base nos arquivos changelog_2.xml e changelog_3.xml, mas não mais a que estava no arquivo changelog_1.xml, logo, realizamos um ROLLBACK dessa alteração. O resultado retornado será conforme a Figura 2.

Captura de Tela 2015-07-10 às 21.39.57
Figura 2. SELECT na tabela de controle databasechangelog na base de Homologação.

No próximo post você aprenderá como efetuar uma refatoração mergeColumn através da ferramenta de versionamento de banco de dados Liquibase. Aprenderá também como usar o comando SQL OUTPUT – UpdateSQL. Através desse comando é possível transformar os XMLs criados para refatorações em comandos SQL.

Banco de Dados Evolutivo – Parte 9

Neste post da série Banco de Dados Evolutivo você aprenderá mais sobre as refatorações no Liquibase e saberá como realizar uma bundled change addColumn.


O Liquibase suporta inúmeros tipos de refatorações em bancos de dados diversos. Estas chamam-se Bundled Changes (Pacote de Mudanças). Você terá acesso a todas elas acessando o seguinte link. Quando você se deparar com uma mudança DDL ou DML que não seja contemplada por seus comandos, existe uma refatoração chamada SQL que permite receber qualquer comando de alteração de banco de dados. Mas você precisa tomar cuidado se em seu ambiente você estiver trabalhando com bancos de dados distintos. Tente sempre usar queryes em padrão ANSI.

Falaremos agora de algumas das refatorações possíveis no Liquibase e faremos também algumas mudanças em nosso ambiente de homologação da Adventure Works. Vamos começar adicionando uma nova coluna para armazenar os dados de CPF na tabela Person.Person. Usaremos, para isso, a refatoração chamada addColumn. Será necessário criarmos um arquivo XML de nome changelog_2.xml usando o código da Listagem 1 e colocá-lo dentro da pasta Versao_1.0.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <changeSet author="arthur" id="add coluna Cpf">
     <addColumn tableName="Person"
               schemaName="Person">
         <column name="Cpf" type="varchar(11)"/>
     </addColumn>
 </changeSet>

 </databaseChangeLog>

Listagem 1. Comando usado dentro do arquivo changelog_2.xml para adicionar à tabela Person.Person a coluna Cpf.

Agora vamos substituir dentro do arquivo master_1.0.xml a tag de inclusão da refatoração changelog_1.xml pela tag contendo o arquivo changelog_2.xml (não queremos recriar a tabela teste_liquibase em nossa base de dados de homologação). Após as alterações, o arquivo master_1.0.xml ficará igual à Listagem 2.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <include file="C:/changelog/versao_1.0/changelog_2.xml" />

 </databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo master_1.0.xml para substituir a tag relacionada ao arquivo changelog_1 pela relacionada ao XML changelog_2.

Agora basta abrir o cmd, acessar a pasta raiz de sistema e executar o comando da Listagem 3 (o mesmo usado para criar a tabela teste_liquibase na Parte 7 da série).

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

Listagem 3. Comando usado no cmd para execução do comando UPDATE através do Liquibase.

Captura de Tela 2015-07-03 às 1.22.36 AM
Figura 1. Coluna Cpf criada na tabela Person.Person na base AdventureWorks_Homolog.

 

Se você alterou e criou tudo corretamente, sua tabela Person.Person da base de dados de Homologação ficará conforme a Figura 1.

 

 


Nos próximos posts da série você aprenderá duas novas Bundled Changes: a AddNotNullConstraint e mergeColumns.

Banco de Dados Evolutivo – Parte 7

Nesse post da série Banco de Dados Evolutivo, você irá efetuar a primeira refatoração no database AdventureWorks_Homolog através da ferramenta de versionamento de banco de dados Liquibase. Iremos aprender um pouco sobre o funcionamento do comando UPDATE (Para informações teóricas sobre este comando, leia a Parte 4 do conjunto de posts).


Antes de iniciarmos, para que fique mais claro do que o exposto na Parte 5 da série e não tenhamos erros futuros, se você executou todos os passos para instalação e configuração do ambiente de testes você percebeu que no link para download do arquivo jdbc para o SQL Server existem várias opções. Você precisará fazer o download do arquivo sqljdbc_4.1.5605.100_ptb.tar.gz. Após o download concluído será necessário que você descompacte o arquivo e copie o sqljdbc4.jar para dentro da pasta do Liquibase que está no diretório C:\ (conforme explicado na Parte 5 do conjunto de posts).

Agora finalmente começaremos os testes na ferramenta Liquibase. Dentro do diretório C:\changelog (gerado com base no post anterior – Parte 6) crie o arquivo master.xml usando o código da Listagem 1.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <include file="C:/changelog/versao_1.0/master_1.0.xml" />

 </databaseChangeLog>

Listagem 1. Comando usado dentro do arquivo master.xml criado.

Após isso, dentro do diretório C:\changelog\versao_1.0 crie o arquivo master_1.0.xml segundo o codigo da Listagem 2.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <include file="C:/changelog/versao_1.0/changelog_1.xml" />

 </databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo master_1.0.xml criado.

Faremos a nossa primeira experiência com a ferramenta criando uma tabela chamada teste_liquibase no nosso banco de dados AdventureWorks_Homolog. Para isso criaremos um arquivo chamado changelog_1.xml (use o código da Listagem 3). Não precisaremos alterar o arquivo master_1.0.xml pois, quando o criamos, já adicionamos a tag que inclui esse XML de refatoração. A tag changeset, como fora dito anteriormente (Parte 4 do conjunto de posts), contém as alterações DDL e/ou DML da base de dados para qual está sendo apontada.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <changeSet author="arthur" id="cria tabela teste_liquibase">
     <createTable
          tableName="teste_liquibase">
             <column name="id" type="integer"/>
             <column name="nome" type="varchar(255)"/>
             <column name="telefone" type="varchar(11)"/>
     </createTable>
 </changeSet>

 </databaseChangeLog>

Listagem 3. Comando usado dentro do arquivo changelog_1.xml criado.

Para que seja possível executar o comando UPDATE é necessário que passemos uma serie de parâmetros via linha de comando para o Liquibase. Para que não seja necessário redigitar todos esses parâmetros todas as vezes que formos realizar alguma alteração em nosso banco de dados é possível que criemos um arquivo de propriedades. Esse arquivo que se chamará liquibase.properties irá armazenar todas as informações necessárias para que possamos trabalhar de forma mais simples. Para criá-lo utilize o código da Listagem 4. Salve-o dentro do diretório do Liquibase localizado em C:\. Atribua aos parâmetros <user> e <password> respectivamente o usuário e senha com permissões de alterações DDL, DML e DCL no database.

driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 
classpath: C:/liquibase-3.0.8-bin/sqljdbc4.jar 
url: jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Homolog 
username: 
password:  
changeLogFile: C:/changelog/master.xml

Listagem 4. Comando usado dentro do arquivo liquibaseHomolog.properties criado.

Observe que por termos os apontamentos realizados através das tags de include dentro do arquivo master.xml, sempre que você o executar, estará efetuando todas as mudanças construídas através dos demais changelogs (Lembrando que graças aos registros dentro da tabela de controle databasechangelog o Liquibase não se perde e refaz algo que já tenha sido executado anteriormente. Ou seja, ele varre essa tabela de controle e procura tudo que foi executado para realizar somente aquilo que ainda não foi executado).

Para realizar o UPDATE abra o cmd, vá para a pasta raiz do sistema operacional e digite os comandos da Listagem 5. Primeiramente o Liquibase é executado. Depois a ferramenta receberá os parâmetros que foram guardados no arquivo liquibaseHomolog.properties e, por último, teremos a execução do comando UPDATE que será responsável pela criação da tabela teste_liquibase na nossa base AdventureWorks_Homolog.

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

Listagem 5. Comando usado no cmd para execução do comando UPDATE através do Liquibase.

capture 1
Figura 1. Tabelas de controle databasechangelog e databasechangeloglock e tabela teste_liquibase.

Após a execução do comando você poderá ver que as duas tabelas de controle (databasechangelog e databasechangeloglock) foram criadas na base AdventureWorks_Homolog. E poderá ver também que temos uma nova tabela chamada teste_liquibase no schema dbo – Veja na Figura 1. Se você realizar um SELECT na tabela databesechangelog será possível observar que ela guardou os dados da alteração executada no campo description. Veja também os campos id e autor – Figura 2.

Capture 2
Figura 2. SELECT executado na tabela de controle databasechangelog após a execução do comando UPDATE.

Caso ao executar o comando da Listagem 5 a tela do cmd apresentar o seguinte erro:

Liquibase update Failed: com.microsoft.sqlserver.jdbc.SQLServerException:
The TC P/IP connection to the host localhost, port 1433 has failed. Error:
 "Connection refused: connect. Verify the connection properties. Make sure
 that an instance o f SQL Server is running on the host and accepting TCP/
IP connections at the port . Make sure that TCP connections to the port 
are not blocked by a firewall.". C:\>
Captura de Tela 2015-06-27 às 2.12.24 AM
Figura 3. Configurando a porta TCP/IP para que o Liquibase consiga acessar o SQL Server.

Você precisará da seguinte configuração:

  1. Abrir o Sql Server Configuration Manager;
  2. Expandir a aba SQL Server Network Configuration;
  3. Clicar em Protocols for <instance_name>;
  4. Abrir a opção TCP/IP (dentro de Protocol Name);
  5. Marcar como YES a opção Enabled (caso esteja diferente disso);
  6. Ir até a aba IP Addresses;
  7. Descer a barra de rolagem até a opção IPAII;
  8. preencher a opção TCP Port com o valor 1433 (Veja a Figura 3).
  9. Reiniciar a instância de banco de dados.

Depois do término da configuração exposta acima, você poderá executar novamente o comando da Listagem 5 que receberá uma mensagem de sucesso.


No próximo post aprenderemos sobre o comando RollbackCount (um dos tipos de rollbacks permitidos pela ferramenta de versionamento de banco de dados Liquibase).