Pessoal, já questionei isso em outros lugares e agora queria saber a opinião de vocês também.
Ainda não usei o migrations, mas estudando ele percebi que é bem manual, conforme confirmado por outro usuário. Ou seja, não existe uma forma de ele automaticamente gerar as classes já com o código baseado no banco atual ou apenas com suas alterações atuais em relação às migrations anteriores.
Portanto, ou não entendi bem ou achei realmente manual ao extremo pois cada alteração no banco eu tenho que ter o cuidado de não esquecer de gerar o migration correto para aquela alteração, caso contrário, quem receber o código pode se deparar com diversos erros. Sem contar na delonga de ter que deixar de usar uma ferramenta de banco de dados para fazer as alterações manualmente no código, ou, continuar a usá-la e aí fazer trabalho dobrado.
Atualmente, o que fiz, já que uso Git, foi criar um script que ao dar commit se encarrega de automaticamente fazer o backup do banco, adicioná-lo ao commit e só então fazer realmente o commit. O arquivo (sql) gerado já é colocado em protected/data e vai sendo atualizado a cada commit. Ou seja, não tem como esquecer de algo, não preciso mexer em nada e não preciso aprender nada novo. Quando eu precisar de outra versão do meu código, receberei junto o sql exato do estado do banco naquela versão.
Obviamente daria pra fazer a atualização do banco automaticamente ao dar um checkout, mas por enquanto não achei necessário.
Então eu pergunto: será que entendi tão mal assim o Migrations ou dessa forma automatizada ‘onCommit’ fica realmente mais fácil?
Na opinião de vocês, quais são os prós e contras de cada método?
Obrigado.