Alterando tabelas de banco de dados no Django

StackOverflow https://stackoverflow.com/questions/35991

  •  09-06-2019
  •  | 
  •  

Pergunta

Estou pensando em usar o Django para um projeto que estou iniciando (para sua informação, um jogo baseado em navegador) e um dos recursos que mais estou gostando é usar syncdb para criar automaticamente as tabelas de banco de dados com base nos modelos Django que defino (um recurso que não consigo encontrar em nenhum outro framework).Eu já estava pensando que isso era bom demais para ser verdade quando vi isso no documentação:

Syncdb não alterará tabelas existentes

O syncdb criará tabelas apenas para modelos que ainda não foram instalados.Ele nunca emitirá instruções ALTER TABLE para corresponder às alterações feitas em uma classe de modelo após a instalação.Mudanças nas classes de modelo e esquemas de banco de dados geralmente envolvem alguma forma de ambigüidade e, nesses casos, o Django teria que adivinhar as mudanças corretas a serem feitas.Existe o risco de que dados críticos sejam perdidos no processo.

Se você fez alterações em um modelo e deseja alterar as tabelas do banco de dados para que correspondam, use o comando sql para exibir a nova estrutura SQL e compare-a com o esquema da tabela existente para calcular as alterações.

Parece que a alteração das tabelas existentes terá que ser feita "manualmente".

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

  • Como sugere a documentação, faça as alterações manualmente no banco de dados;
  • Faça um backup do banco de dados, limpe-o, crie as tabelas novamente (com o syncdb, já que agora está criando as tabelas do zero) e importe os dados do backup (isso pode demorar muito se o banco de dados for grande)

Alguma ideia?

Foi útil?

Solução

Conforme observado em outras respostas ao mesmo tópico, não deixe de assistir ao Painel de evolução do esquema DjangoCon 2008 no YouTube.

Além disso, dois novos projetos no mapa: Migrações simples e Migratório.

Outras dicas

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

EDITAR:E ei, aí vem migrações.

ATUALIZAR:Como esta resposta foi escrita originalmente, evolução do Django e migrações cessaram o desenvolvimento ativo e Sul tornou-se o padrão de fato para migração de esquema no Django.Partes do Sul podem até ser integradas ao Django nas próximas versões.

ATUALIZAR:Uma estrutura de migração de esquema baseada em South (e de autoria de Andrew Godwin, autor de South) está incluída no Django 1.7+.

Uma boa maneira de fazer isso é através de fixtures, particularmente o initial_data luminárias.

Um fixture é uma coleção de arquivos que contém o conteúdo serializado do banco de dados.Então é como ter um backup do banco de dados, mas como é algo que o Django conhece, é mais fácil de usar e terá benefícios adicionais quando você fizer coisas como testes unitários.

Você pode criar um fixture a partir dos dados atualmente em seu banco de dados 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 guardar utensílios é um fixtures subdiretório dos diretórios do seu aplicativo.

Você pode carregar um fixure usando django-admin.py loaddata mas mais significativamente, se o seu aparelho tiver um nome como initial_data.json ele será carregado automaticamente quando você fizer um syncdb, evitando o trabalho de importá-lo você mesmo.

Outro benefício é que quando você corre manage.py test para executar seus testes de unidade, o banco de dados de teste temporário também terá o dispositivo de dados inicial carregado.

Claro, isso funcionará quando você adicionar atributos a modelos e colunas ao banco de dados.Se você eliminar uma coluna do banco de dados, precisará atualizar seu equipamento para remover os dados dessa coluna, o que pode não ser simples.

Isso funciona melhor ao fazer pequenas alterações no banco de dados durante o desenvolvimento.Para atualizar bancos de dados de produção, um script SQL gerado manualmente pode funcionar melhor.

Eu tenho usado a evolução do Django.As advertências incluem:

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

Dito isto, acho o costume schema_evolution.py abordagem útil.Para contornar o problema da impressão digital, sugiro códigos 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 alterações, eu refatoraria.Até então, torná-lo mais limpo seria roubar tempo de desenvolvimento de outra coisa.

EDITAR: Dado que estou construindo manualmente minhas alterações de qualquer maneira, tentarei migrações próxima vez.

extensões de comando Django é uma biblioteca Django que fornece alguns comandos extras para manager.py.Um deles é o sqldiff, que deve fornecer o sql necessário para atualizar para o seu novo modelo.É, no entanto, listado como “muito experimental”.

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

Geralmente não temos tantas mudanças de esquema nos sistemas de produção e implementações um tanto formalizadas do desenvolvimento para os servidores de produção.Sempre que implementamos (10 a 20 vezes por ano), fazemos uma comparação de preenchimento entre o ramo de produção atual e o futuro, revisando todo o código e observando o que precisa ser alterado no servidor de produção.As alterações necessárias podem ser dependências adicionais, alterações no arquivo de configurações e alterações no banco de dados.

Isso funciona muito bem para nós.Ter tudo automatizado é uma visão de nicho, mas muito difícil para nós - talvez pudéssemos gerenciar migrações, mas ainda precisaríamos lidar com bibliotecas, servidores adicionais, quaisquer dependências.

Django 1.7 (atualmente em desenvolvimento) é adicionando suporte nativo para migração de esquema com manage.py migrate e manage.py makemigrations (migrate deprecia syncdb).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top