| Autor |
Mensagem |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 03/01/2010 22:40:35
|
tnaires
GUJ Master
![[Avatar]](/images/avatar/5f6371c9126149517d9ba475def53139.png)
Membro desde: 22/12/2003 08:05:58
Mensagens: 1678
Localização: Porto Alegre/RS - Natal/RN
Offline
|
Olá pessoal, feliz ano novo a todos.
É comum que o lançamento de uma nova versão de um aplicativo contenha muitas modificações no banco de dados: algumas colunas adicionadas, outras removidas, novas tabelas criadas, etc. Como vocês costumam granularizar as migrations que envolvem essas alterações?
Por exemplo, vamos supor que uma atualização de um determinado aplicativo contenha a adição de dois campos a uma tabela e a remoção de um campo em outra. O mais adequado seria ter uma migration por tabela, uma migration por coluna ou apenas uma migration abrangendo todas as modificações?
Abraço.
|
Tarso Nunes Aires
Blog - http://cabritin.wordpress.com/
Delicious - http://delicious.com/tnaires
Twitter - @tnaires
 |
|
|
 |
|
|
![[Post New]](/templates/default/images/icon_minipost_new.gif) 08/01/2010 10:20:02
|
urubatan
Moderador
![[Avatar]](/images/avatar/fe9fc289c3ff0af142b6d3bead98a923.jpg)
Membro desde: 21/09/2002 10:31:26
Mensagens: 2481
Localização: Porto Alegre/RS
Offline
|
é barbada, é só não pensar nisto
Um exemplo:
Te mandaram criar um cadastro novo, cria uma migration, implementa o cadastro e comita tudo.
Depois te mandaram remover um campo de um cadastro já existente
cria uma migration para fazer a alteração no banco
implementa a alteração e comita
assim tu tem migration por alteração no sistema, que é o mais correto na minha opinião, e não por versão do sistema, que normalmente inclui diversas alterações.
|
[]'s
Rodrigo Urubatan
http://www.urubatan.com.br
Melhor livro de RoR do brasil: http://livro.urubatan.com.br
|
|
|
 |
|
|
|
|