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:
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:
- 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);
- é inserido 2 underscore (__) após a versão do arquivo;
- é 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!
Top comments (4)
Muito legal @fllaviacorreia! Parabéns!
Gosto bastante do flyway, mas, com o tempo fui tendendo ao Liquibase por ser mais fácil, acho que vale a pena dar uma olhadinha!
Valeu Lucas !
Vou olhar ele depois e dar um review!
Massa de mais!
Valeu Túlio! :D