Doctrine: Migrations, relatórios e performance

Migrations - Apresentação

Oi, pessoal, sejam muito bem-vindos a Alura. Eu sou o Vinicius Dias e vou guiá-los nesse treinamento, em que vamos nos aprofundar no conhecimento de Doctrine. No curso anterior, já falamos que Doctrine é um ORM, entendemos o que é um ORM, aprendemos a trabalhar com Entity Manager, fizemos um CRUD e, inclusive, já criamos relatórios.

Neste treinamento, vamos avançar nesse conhecimento, melhorando a performance daqueles relatórios, vendo como podemos ter um versionamento do nosso banco e como fazer para que as alterações no banco sejam feitas de forma bem suave, inclusive pela equipe de desenvolvimento.

Vamos falar sobre outra sintaxe para escrever os nossos relatórios (o que, de novo, pode ajudar na nossa performance) e vamos conversar bastante sobre o cache — vários tipos de cache que o Doctrine nos fornece.

No final, vamos bater um papo sobre como Doctrine se integra com outros frameworks, e vamos, inclusive, migrar de SQLite para MySQL durante esse treinamento. Então, este curso está recheado de conteúdo novo. Se em algum momento você ficar com qualquer dúvida, não hesite, abra um tópico no fórum. Eu tento responder sempre que eu consigo. Quando eu não consigo, temos uma grande comunidade de alunos, moderadores, instrutores e, com certeza, alguém conseguirá te ajudar.

Eu te espero no próximo vídeo para já explicar como podemos ter um versionamento do nosso banco de dados, utilizando o Doctrine.

Migrations - Conhecendo o conceito

Olá, pessoal, bem-vindos de volta. Então, já vimos no treinamento anterior que o Doctrine pode criar um banco de dados para nós e ele pode atualizar o esquema do banco de dados, levando em consideração nosso mapeamento, só que isso tem alguns problemas.

Primeiro, se dermos uma olhada na lista de comandos do Doctrine, quando executamos o comando schema-tool:create, ele exibiu um aviso de “Cuidado”, uma mensagem em vermelho falando: “Cuidado, isso não deve ser executado em produção”. Porque quando executamos esse comando, o Doctrine está sendo responsável por criar, otimizar e fazer tudo no banco de dados, e nem estamos revisando.

Então, a primeira possibilidade é executar esse comando $ php bin/doctrine.php orm:schema-tool-create –dump-sql, com a opção --dump-sql. Dessa forma, ele não vai executar nada, só nos mostrará o SQL que ele executaria.

Poderíamos enviar isso para um administrador de banco de dados (por exemplo, o famoso DBA) ou consultar com alguma pessoa que tem mais experiência em banco de dados, e saber se os índices estão sendo criados corretamente, se o relacionamento está certo, se precisamos de algum índice a mais, ou algum a menos. Então, podemos ter um pouco mais de controle.

Isso já é uma alternativa mais interessante. Só que tem outro problema: nós criamos primeiro a nossa tabela de aluno, a nossa “Student”. Depois, nós criamos a tabela de “Phone” e, depois, de “Course”. Então, fomos alterando o nosso banco de dados. Em um cenário real, é muito comum precisarmos adicionar uma tabela, adicionar uma coluna dentro de uma tabela ou até remover algo — ou seja, realizar alterações no banco de dados.

Então, imagina se, a cada alteração, eu preciso executar um comando do schema-tool-update para fazer esse --dump-sql, e eu mando para o DBA ou mando para quem vai analisar essa estrutura.

Só que repara que, às vezes, ele executa coisas demais, então já não gostei dessa ideia, ele está fazendo coisas desnecessárias. Além disso, em um cenário um pouco mais real em que estamos utilizando um banco de dados mais simples de manipularmos (como o MySQL, o Postgres), imagina toda vez mandar isso para um DBA e, quando outra pessoa que for desenvolver for executar isso, vai precisar verificar também, executar todos os comandos, sem saber o que está sendo feito.

Agora, um terceiro ponto é que quando escrevemos código, é muito comum utilizarmos um versionamento de código, por exemplo, o Git, que é mais utilizado. A cada pequena modificação no nosso código, adicionamos um commit, adicionamos um ponto de alteração no nosso código. Seria muito interessante se pudéssemos ter isso no banco de dados.

Imagina que eu fiz uma alteração e gerei o schema-tool-update, fiz o --dump-sql do meu update e salvei tudo que precisa ser executado para atualizar o meu banco. E se essa alteração der errado, se essa release que eu fiz der errado, como eu vou reverter essas alterações?

Então, se não temos um versionamento utilizando o Git, por exemplo, esse tipo de tarefa fica bem difícil. Ou seja, temos dois pontos muito importantes, além de todo esse controle, conversar com outras pessoas da equipe, temos dois pontos muito interessantes: armazenar um histórico de alterações no nosso banco de dados, para saber como o banco evoluiu com o tempo, e a possibilidade de reverter as alterações. Isso é mais importante ainda.

Então, seria interessante utilizarmos alguma ferramenta que versionasse o nosso banco de dados, que fosse um sistema de versão do nosso esquema do banco de dados. E o Doctrine ORM, ou o Doctrine DBAL, não faz isso. Só que lembra que eu comentei no treinamento anterior que o Doctrine é um projeto? E que, nesse projeto, temos diversos componentes, diversos pacotes?

Um desses pacotes se chama Migrations. Esse componente permite que, utilizando a camada de abstração do Doctrine, realizemos modificações e temos a possibilidade de reverter essas modificações no banco de dados.

Esse pacote de migrations é o que vamos conhecer no próximo vídeo.

Migrations - Instalando o componente

Oi, pessoal, bem-vindos de volta. Então, eu quero ter todas essas vantagens: Versionar meu banco de dados, quando tiver alguma mudança, eu quero só “commitar” esse arquivo de migration, e os outros desenvolvedores podem rodar e atualizar seu banco só com o necessário, sem precisar rodar o comando de update do banco inteiro.

Enfim, já falamos sobre as vantagens, então, vamos instalar esse componente de migrations. Então, conseguimos ver que é um comando do Composer. Vou no meu terminal, enquanto ele executa composer require doctrine/migrations, eu vou dar uma lida na documentação.

Ele explica o que é essa documentação, e temos um guia de introdução às migrations. Recomendo que você leia, mas eu vou só seguir o passo a passo. Ele está nos dizendo para criarmos uma pasta para o nosso projeto, já temos essa pasta, o projeto já está rodando.

Ele nos falou para instalar, nós já instalamos. Agora, ele diz para executar o comando ./vender/bin/doctrine-migrations, só que eu não vou executar ainda, porque vamos ter alguns problemas, e eu vou te explicá-los agora.

Eu vou abrir o nosso projeto de novo, limpar a minha tela e minimizar o terminal. Nós criamos, no primeiro treinamento, arquivos de configuração para o Doctrine ORM ter aquela série I, aquela interface da linha de comando. Esses dois arquivos foram o arquivo em que executamos o Doctrine, e isso utilizando o formato do Doctrine 3 já, então, esse é o ideal. E fizemos com uma versão antiga, com a versão 2 do Doctrine, que é criando esse cli.config.php.

Essa linha de comando é do Doctrine Migrations, ou seja, não é mais ORM, é o de migrations. Essa linha de comando também pode ler esse arquivo, só que esse arquivo do jeito que ele está, ele não está completo para o Migrations, para o componente de Migrations ler. Então, isso vai trazer mais problemas do que soluções. Nós conseguimos resolver, então, caso você esteja trabalhando com a versão antiga do Doctrine, não queira ainda fazer as atualizações, mas queira utilizar os migrations, vai funcionar.

Só que, para o nosso caso ser um pouco mais simples de configurar, eu vou remover esse cli-config-php, eu vou apagar esse arquivo. Então, com esse arquivo apagado, eu posso rodar aquele comando vendor/bin/doctrine-migrations.

Então, repara que temos alguns comandos que podem ser executados. O comando que executa todas as migrations, que faz realmente a migrations do nosso banco de dados seria o migrations:migrate. Então, eu vou tentar executar, $ php vender/bin/doctrine-migrations migrations:migrate. E vamos ter alguns problemas, você já deve imaginar alguns deles.

Quando eu executo, ele não conseguiu encontrar nenhum arquivo de configuração. Então, precisamos fornecer para o Doctrine Migrations suas configurações. Então, eu vou minimizar o terminal de novo e voltar para a documentação. Ele mostra outra forma de instalar, já instalamos utilizando o Composer, então está tudo certo.

Agora, vamos para o próximo capítulo, que é o de configurações. Ele diz para criarmos uma pasta, em que vamos guardar as migrations em si, os arquivos que vão ter todas as alterações do banco de dados. Então, vou criar essa pasta. Você pode criar onde quiser, pode ser no src, dentro de uma pasta migration, com namespace migration, mas eu vou criar na raiz mesmo, só por opção, você pode, de novo, criar onde você quiser.

Criei essa pasta “Migrations”, agora, vamos utilizar esse arquivo de exemplo, e ele pode ser em .yaml, .xml, .json, mas eu vou utilizar .php mesmo. E o nome dele precisar ser migrations, então, eu vou copiar esse arquivo e criar em migrations.php, na raiz do meu projeto. Esse arquivo precisa estar na pasta em que executamos o comando Doctrine Migrations.

Então, podemos passar o olho nessas configurações. Em ‘table-storage’ vai ter a informação de onde o componente vai guardar as informações do que já foi executado, qual a versão da migration que rodou, quais são as colunas dessa tabela em que ele vai guardar as migrations, e eu vou deixar tudo padrão.

Em ‘migrations_paths’ informamos os caminhos em que vamos ter as migrations. Então, eu tenho um namespace e o caminho em que esses caminhos vão existir. Como namespace, eu vou deixar só migrations mesmo, eu poderia ter ’Alura\\Doctrine\Migrations’, como temos feito, inclusive, eu vou deixar assim só para mantermos o padrão.

E no caminho, e eu vou colocar a partir do diretório atual, dentro da pasta “Migrations”, que é a pasta que criamos. E eu não preciso dessa segunda linha, eu posso ter vários caminhos, vários diretórios em que existem migrations, mas eu só vou ter uma, no nosso caso.

E temos outras configurações que não precisamos nos atentar, esse padrão funciona bem, mas basicamente, se eu tivesse vários Entity Manager, eu informaria o nome do que vamos usar. Se eu tenho várias conexões, eu informo o nome da conexão que vamos usar. Vamos deixar nulo, porque vamos informar a conexão em outro lugar.

A forma de organizar as migrations, se elas vão estar dentro de uma transação, e se todas as migrations vão estar dentro da mesma transação, e podemos configurar isso tudo, inclusive na documentação está explicando o que é cada uma dessas configurações.

Eu recomendo, de novo, que você leia tudo isso com calma. Agora, será que com isso, quando eu executar esse comando $ php vender/bin/doctrine-migrations migrations:migrate já vai tudo funcionar? Vamos ver o que acontece.

Quando eu executo isso, ele diz que o arquivo de configurações no banco de dados não existe, porque o nosso ORM sabe como se conectar ao banco, porque informamos na hora de criar o Entity Manager. Mas o nosso componente de migrations não sabe qual banco de dados utilizar, então, precisamos do arquivo migratons-db.

Então, eu copiei e vou colar no campo de nome do novo arquivo PHP migratons-db , esse é nome do arquivo que eu vou criar.

E esse arquivo precisa retornar em formato de array aquela informação de conexão, igual criamos para o Entity Manager. Inclusive, podemos acessar a nossa classe do EntityManager, e eu posso copiar o $conn dele. E eu vou colar no arquivo que acabei de criar. Só que eu preciso corrigir o caminho do arquivo, porque ele está direto na raiz.

Então, se eu estou dizendo que o Doctrine Migrations vai utilizar SQLite como driver, e o caminho do banco que ele vai utilizar é esse. Teoricamente, agora está tudo certo. Se eu executar esse comando migrate, vai ter um último aviso, um último erro, informando que ele vai executar isso em um banco de dados e que, nas migrations que ele vai utilizar, pode inclusive ter perda de dados.

Nessa migration, podemos ter um drop table por exemplo, remover uma tabela. Podemos ter um drop columns, removendo uma coluna, isso é possível, então, ele nos avisa para termos cuidado. Eu vou confirmar que eu quero continuar, e agora, ele informa que não encontrou nenhuma migration, o que é de se esperar, porque nós configuramos tudo correto, configurado, mas não temos nenhuma migraton.

Então, falta esses detalhes para utilizarmos esse componente. Então, no próximo vídeo, vamos ver como criar *migrations.

Sobre o curso Doctrine: Migrations, relatórios e performance

O curso Doctrine: Migrations, relatórios e performance possui 136 minutos de vídeos, em um total de 47 atividades. Gostou? Conheça nossos outros cursos de PHP em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Migrations
• Relatórios e DQL
• Queries e repositórios
• Doctrine cache
• Integrações