Para quem já criou tabelas com SQL puro direto no phpmyadmin, migrations são uma revolução. Assim como git versiona seu código fonte, migrations são uma forma de versionar seu banco de dados.
Veja documentação sobre Migrations no CodeIgniter
Usando migrations fica mais fácil estruturar seu DB e ter um histórico da sua evolução.
CodeIgniter Database Migrate: explicação dos comandos
- migrate - monta banco de dados apenas, acionando método up() das migrations. Se criar uma nova migration, use esta opção
- migrate:rollback - desmonta banco de dados apenas, acionando método down() das migrations
- php spark migrate:rollback -b 1 : exemplo de rollback que volta para o batch 1
- migrate:refresh - desmonta e monta: faz o 'migrate:rollback' e depois faz o 'migrate'
- migrate:status - gera um relatório dos estados da migrations
Com os comandos acima fica mais fácil automatizar várias tarefas no BD: limpar, destruir, reconstruir, voltar para uma versão anterior, colocar dados fake, reconstruir o DB em outro local, etc.
E com estas tarefas já automatizadas, agora o desafio é pensar em como estruturar melhor as migrations.
Criar um novo campo: editar uma migration CREATE TABLE ou criar uma nova migration com ALTER TABLE?
No projeto custom-content decidi criar um novo campo chamado 'assunto' na entidade 'template'. A partir daí veio uma dúvida: Qual a melhor forma de atualizar o aplicativo criando um novo campo?
Creio que a forma de resolver isso depende do status do projeto, se está em produção ou não. Duas opções me vieram a cabeça:
Opção A: Devo atualizar a migration CREATE TABLE apenas adicionando um novo campo 'assunto'?
Penso que a 'Opção A' (mais simples) seria mais indicada caso o sistema não fosse lançado em produção, pois bastaria atualizar a migration de CREATE TABLE, usar um migrate:refresh (deletaria dados de teste no banco de dados) e pronto.
Opção B: Devo criar uma nova migration com ALTER TABLE adicionando um novo campo 'assunto'?
Penso que a 'Opção B' (mais complexa) seria mais indicada caso o sistema esteja em produção. Neste caso necessitaria adicionar o campo 'assunto' e replicar os mesmos dados do campo 'nome' para 'não quebrar o sistema'. O envio de email usa o campo 'nome' da campanha, agora vai usar o campo 'assunto' do template e, portanto, este não pode estar vazio.
A decisão
Por fim decidi que a 'opção B' é a melhor alternativa, pois é mais difícil de implementar (excelente para fins didáticos) e penso que será aplicável nos dois cenários: tanto desenvolvimento quanto em produção.
Pela minha experiência em programação, talvez esta solução seja incompleta - até mesmo irrelevante - pois pode haver pontos os quais ainda não enxerguei. Ao correr com este projeto na pista DevOps (em formato de infinito), novas reflexões surgirão? E se este sistema estivesse em produção e com dados de usuários, aplicar esta migration seria o método mais eficaz?
O que achou destas reflexões? Deixe seu comentário!
Top comments (0)