Faala pessoal! Tudo bem?

Estou de volta para mais um post sobre o projeto Rest API e para relembrar sobre o que já foi mostrado, deixo essa lista dos articles já publicados:

• Primeiro post
• Segundo post
• Terceiro post
• Quarto post

Ferramentas utilizadas

Para o post de hoje, irei falar com vocês sobre persistência de dados, nessa situação estarei utilizando o Jakarta Persistence API, Spring Data JPA e FlyWay (FW). É nesse ponto que iremos utilizar o banco de dados relacional MySQL, mas fica a seu critério se adaptar e utilizar o seu DB preferido.

• Adicione o Spring Data JPA, FlyWay Migration e o MySQL Driver ao projeto; nesse ponto aqui, eu tive um problema com o drive do MySQL, então no pom.xml alterei a dependência do driver para:

<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>

Configurando a conexão com o banco de dados

• Adicione as informações do banco de dados no arquivo application.properties que está dentro do pacote resources:

Como gerar migrations

• Crie dentro de src/main/resources uma pasta 'db' e uma subpasta 'migration'.

É nelas que estarão todos os arquivos referentes ao banco de dados, como os scripts de criação/alteração/deleção de tabelas, colunas, etc..

Por padrão, o FW só lê os scripts com nome em determinado padrão, por padrão o FW percebe:

1. arquivos iniciados com 'V', maiúsculo mesmo, e ai a identificação do arquivo fica a seu critério, com índice (V0001) ou data e hora (V20221213213045 - meu formato aqui está YYYY/MM/DD-HH:MM:SS)(eu vou seguir com a primeira opção);
2. é inserido 2 underscore (__) após a versão do arquivo;
3. é inserido a descrição do arquivo junto com a extensão .sql (p.e. create-table-books.sql)

Então no final fica:

• V0001__create-table-books.sql

ou

• V20221213213045__create-table-books.sql

OBS.: Se o projeto estiver rodando, quando criar o arquivo com a extensão .sql o devtools vai fazer o seu papel de reiniciar o servidor e o FW vai rodar o script vazio e isso vai gerar uma mudança no DB e ficar registrado na tabela referente ao FW que foi criada, a com nome flyway_schema_history.

É nessa tabela que são guardadas as infos referentes ao banco, como por exemplo quais os schemas rodados.

Então, eu recomendo que, com o servidor inativo, crie os arquivos com a versão e extensão e, só depois de tudo certo, com o DDL inserido no arquivo, inicie o servidor.

Você pode também fazer isso com o servidor ativo, ai pode criar o arquivo com o nome (ex. create-table-books.sql) e só depois alterar o nome do arquivo para o padrão.

Modificando a Model de Editora e criando a migration

Como iniciei com o Model de Editora, vou criar o DDL de editora da seguinte forma:

• criei o arquivo V0001__create-table-publishing-companies.sql

• adicionei o schema:

CREATE TABLE IF NOT EXISTS publishing_companies(
id BIGINT NOT NULL AUTO_INCREMENT,
name VARCHAR(200) NOT NULL,
city VARCHAR(50) NOT NULL,
state VARCHAR(5) NOT NULL,
country VARCHAR(100) NOT NULL,
PRIMARY KEY (id)
)

• alterei a model de editora para garantir a persistência de dados e indicar que é uma table do banco:

a. nas linhas 13 e 20 eu chamei mais uma funcionalidade do Lombok que é a geração de hash code e equals, se não tivesse o código iria fica muito poluído:

b. a linha 16 está indicando que a classe é uma entidade no banco de dados e na linha 17 referencio a tabela do DB com o nome "publishing_companies", caso o nome da tabela fosse equivalente ao do Model, então não precisaria utilizar o Table(name = "name_table_reference")

c. na linha 21 estou indicando que o atributo "id" é referencia à coluna ID da tabela;

d. na linha 22 estou indicando que o ID da tabela será gerado a partir do padrão do banco, por isso a passagem do strategy por parâmetro.

e. repare que nos atributos seguintes não coloquei nenhuma anotação para identificar que são colunas na tabela publishing_companies, isso acaba se tornando opcional, nesse caso, porque o nome é igual. Caso não fosse esse o caso, passaria a anotação @Column(name = "nome_column")

f. se deseja entender melhor sobre @Entity e @Table, tem uma disussão no Stack Overflow sobre esse assunto aqui.

Modificando o controlador

• modifiquei o GET de editora para fazer uma busca no banco de dados:

a. criei um atributo do tipo EntityManager para gerenciar o banco

b. a partir dele, chamei o método para criar uma query e a busca foi feita usando JPQL com o formato da classe de editora.

c. o resultado é convertido em uma lista do tipo do model de editora e retornado para quem solicitou a busca.

Como resultado, após iniciar o servidor, tive:

1 resultado no DB:

a. duas tables criadas

b. a table do Flyway com 1 resultado e a column success = 1

c. a table de editora criada com o nome: publishing_companies e todos os atributos passados no DDL

2 resultado no Postman:

Bom pessoal, por enquanto é isso.

Na próxima publicação, vou trazer um tutorial sobre salvamento, deleção e alteração de dados.

Se tiver alguma dúvida, deixa nos comentários, críticas e sugestões também são bem vindas.

Até mais!