Alterando tabelas de banco de dados em Django

votos
59

Estou pensando em usar Django para um projeto que estou começando (fyi, um jogo baseado em browser) e uma das características que eu estou gostando mais está usando syncdbpara criar automaticamente as tabelas de banco de dados com base nos modelos de Django eu defino (a característica que eu não consigo encontrar em qualquer outro quadro). Eu já estava pensando que isso era bom demais para ser verdade, quando eu vi isso na documentação :

Syncdb não altera tabelas existentes

syncdb só vai criar tabelas para modelos que ainda não foram instalados. Isso nunca vai emitir instruções ALTER TABLE para combinar as alterações feitas em uma classe de modelo após a instalação. Mudanças para classes de modelo e esquemas de banco de dados muitas vezes envolvem alguma forma de ambigüidade e, nesses casos, Django teria que adivinhar as alterações corretas para fazer. Há um risco de que dados críticos seriam perdidos no processo.

Se você tiver feito alterações em um modelo e deseja alterar as tabelas de banco de dados para corresponder, use o comando SQL para exibir a nova estrutura SQL e que ao comparar o seu esquema de tabela existente para trabalhar as mudanças.

Parece que alterar tabelas existentes terão de ser feito à mão.

O que eu gostaria de saber é a melhor maneira de fazer isso. Duas soluções vêm à mente:

  • Como a documentação sugere, fazer as alterações manualmente no DB;
  • Faça um backup do banco de dados, limpe-o, criar as tabelas novamente (com syncdb, já que agora ele está criando as tabelas a partir do zero) e importar os dados de backup (isso pode levar muito tempo se o banco de dados é grande)

Alguma ideia?

Publicado 30/08/2008 em 15:36
fonte usuário
Em outras línguas...                            


8 respostas

votos
59

Fazer as alterações manualmente SQL e despejar / recarga são as duas opções, mas você também pode querer verificar para fora alguns dos pacotes pelo esquema de evolução para Django. As opções mais maduras são django-evolution e do Sul .

EDIT : E ei, aqui vem dmigrations .

ATUALIZAÇÃO : Uma vez que esta resposta foi originalmente escrito, django-evolution e dmigrations ter ambos cessou desenvolvimento ativo e do Sul tornou-se o padrão de fato para a migração de esquema no Django. Partes do Sul pode até ser integrado em Django dentro da próxima versão ou dois.

ATUALIZAÇÃO : Um quadro de esquema-migrações com base em Sul (e autoria de Andrew Godwin, autor do Sul) está incluído no Django 1.7+.

Respondeu 30/08/2008 em 15:56
fonte usuário

votos
16

Como observado em outras respostas para o mesmo tema, não se esqueça de assistir ao DjangoCon 2008 Painel de evolução de esquema no YouTube.

Além disso, dois novos projetos no mapa: Simplemigrations e migratórias .

Respondeu 09/10/2008 em 13:16
fonte usuário

votos
9

Uma boa maneira de fazer isso é através de dispositivos elétricos, particularmente os initial_dataacessórios.

Um dispositivo elétrico é uma coleção de arquivos que contém os conteúdos serializados do banco de dados. Então, é como ter um backup do banco de dados, mas como é algo Django está ciente de que é mais fácil de usar e terá benefícios adicionais quando você vem para fazer coisas como testes de unidade.

Você pode criar um dispositivo elétrico a partir dos dados atualmente em seu DB usando django-admin.py dumpdata. Por padrão os dados estão no formato JSON, mas outras opções, como XML estão disponíveis. Um bom lugar para armazenar luminárias é um fixturessub-diretório de seus diretórios de aplicativos.

Você pode carregar uma fixure usando django-admin.py loaddata, mas de forma mais significativa, se o seu dispositivo tem um nome como initial_data.jsonele será carregado automaticamente quando você faz um syncdb, poupando o trabalho de importação-lo sozinho.

Outra vantagem é que quando você executar manage.py testpara executar o seu Unidade Testes de banco de dados de teste temporário também terá a inicial de dados do dispositivo elétrico carregado.

Claro, isso vai funcionar quando quando você está adicionando atributos para modelos e colunas para o DB. Se você deixar cair uma coluna do banco de dados que você precisa para atualizar seu dispositivo elétrico para remover os dados para essa coluna que pode não ser simples.

Isso funciona melhor quando fazendo lotes de pequenas alterações de banco de dados durante o desenvolvimento. Para atualizar a produção de bancos de dados de um script SQL gerado manualmente muitas vezes pode funcionar melhor.

Respondeu 30/08/2008 em 15:57
fonte usuário

votos
4

Estou usando o django-evolution. Advertências incluem:

  • Suas sugestões automáticas foram uniformemente podre; e
  • Sua função de impressão digital retorna valores diferentes para o mesmo banco de dados em diferentes plataformas.

Dito isto, acho que o costume schema_evolution.pyabordagem acessível. Para contornar o problema de impressão digital, sugiro código como:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Se eu tivesse mais impressões digitais e as mudanças, eu re-fator-lo. Até então, tornando-o mais limpo seria roubar o tempo de desenvolvimento de outra coisa.

EDIT: Uma vez que eu estou construindo manualmente as minhas alterações de qualquer maneira, eu vou tentar dmigrations próxima vez.

Respondeu 11/09/2008 em 03:44
fonte usuário

votos
3

django-extensões de comando é uma biblioteca de Django que dá alguns comandos extra para manage.py. Um deles é sqldiff, que deve dar-lhe o sql precisava atualizar para o seu novo modelo. É, no entanto, listado como 'muito experimental'.

Respondeu 12/09/2008 em 00:33
fonte usuário

votos
2

Django 1,7 (actualmente em desenvolvimento) está adicionando suporte nativo para a migração do esquema com manage.py migratee manage.py makemigrations( migratedeprecates syncdb).

Respondeu 17/12/2013 em 18:23
fonte usuário

votos
2

O livro Django explica como fazê-lo com a mão.

http://www.djangobook.com/en/2.0/chapter10/

Tenho feito isso dessa maneira muitas vezes, e é muito flexível, permitindo que você deixe de dados nas tabelas enquanto remove-los a partir do modelo.

Comecei a usar Sul recentemente. Parece um pouco menos flexível (ou talvez eu só precisa ler os docs um pouco mais.) Mas você pode economizar um pouco de digitação. Às vezes você consegue obtê-lo fora de sincronia com o banco de dados, que é um pesadelo. Parece ir muito bem contanto que você continuar a usar it.It parece amarrar as modelos e banco de dados real juntos, o que pode ou não pode ser uma coisa boa, dependendo da sua situação

Respondeu 13/06/2012 em 09:24
fonte usuário

votos
2

Até agora na minha empresa temos utilizado a abordagem manual. O que funciona melhor para você depende muito do seu estilo de desenvolvimento.

Nós geralmente não têm tantas mudanças de esquema nos sistemas de produção e lançamentos um pouco formalizados de desenvolvimento para servidores de produção. Sempre que rolar para fora (10-20 vezes por ano) fazemos um diff preenchimento do atual e do próximo ramo de produção revendo todo o código e observando o que tem que ser mudado no servidor de produção. As mudanças necessárias podem ser dependências adicionais, alterações ao arquivo de configurações e alterações ao banco de dados.

Isso funciona muito bem para nós. Ter tudo automatizado é uma visão nicho, mas a difícil para nós - talvez pudéssemos gerir as migrações, mas nós ainda precisa lidar com biblioteca adicional, servidor, seja qual for dependências.

Respondeu 04/01/2009 em 15:26
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more