Django fluxo de trabalho quando modificar modelos com freqüência?

votos
25

como eu normalmente não fazer o design da frente para cima dos meus modelos em projetos Django eu acabar modificando os modelos muito e excluindo, assim, o meu banco de dados de teste de cada vez (porque syncdb nunca vai alterar as tabelas automaticamente para você). Abaixo encontra-se o meu trabalho e eu gostaria de ouvir sobre o seu. Quaisquer pensamentos boas-vindas ..

  1. Modificar o modelo.
  2. Excluir o banco de dados de teste. (Sempre um banco de dados SQLite simples para mim.)
  3. Execute syncdb.
  4. Gerar alguns dados de teste através de código.
  5. Goto 1.

A questão secundária em relação a este .. No caso do seu fluxo de trabalho é como acima, como você executar o passo 4.? Você gerar os dados de teste manualmente ou há um ponto de gancho adequado no Django aplicativos onde você pode injetar o gerador de código de teste-dados na inicialização do servidor? \

TIA.

Publicado 31/01/2009 em 00:18
fonte usuário
Em outras línguas...                            


6 respostas

votos
22

As etapas 2 e 3 pode ser feito em uma única etapa:

manage.py reset appname

Passo 4 é mais facilmente gerido, a partir de minha compreensão, usando dispositivos elétricos

Respondeu 31/01/2009 em 00:29
fonte usuário

votos
15

Este é um trabalho para luminárias do Django. Eles são convenientes porque eles são de banco de dados independente e o equipamento de teste (e manage.py) têm suporte embutido para eles.

Para usá-los:

  1. Configure seus dados em seu aplicativo (chamá-lo de "foo"), utilizando a ferramenta de administração
  2. Crie um diretório luminárias em sua "foo" diretório app
  3. Tipo: python manage.py dumpdata --indent=4 foo > foo/fixtures/foo.json

Agora, depois de o seu estágio syncdb, basta digitar:

 python manage.py loaddata foo.json

E seus dados serão recriados.

Se você quer que eles em um caso de teste:

class FooTests(TestCase):
    fixtures = ['foo.json']

Note que você terá de recriar ou atualizar manualmente seus dispositivos elétricos se seu esquema muda drasticamente.

Você pode ler mais sobre luminárias nos docs django para fixação Carregando

Respondeu 31/01/2009 em 00:32
fonte usuário

votos
12

Aqui é o que fazemos.

  1. Apps são nomeados com um número de versão do esquema. appa_2, appb_1, Etc.

  2. Pequenas mudanças não alterar o número.

  3. Grandes mudanças incrementar o número. Syncdb funciona. E um script "migração de dados" pode ser escrito.

    def migrate_appa_2_to_3():
        for a in appa_2.SomeThing.objects.all():
            appa_3.AnotherThing.create( a.this, a.that )
            appa_3.NewThing.create( a.another, a.yetAnother )
        for b in ...
    

O ponto é que eliminar e recriar nem sempre é apropriado. Às vezes é útil para mover dados formam o modelo antigo para o novo modelo sem reconstruir a partir do zero.

Respondeu 31/01/2009 em 03:39
fonte usuário

votos
11

Sul é o mais legal.

Embora boa ol de reset' funciona melhor quando os dados não importa.

http://south.aeracode.org/

Respondeu 12/03/2009 em 01:33
fonte usuário

votos
4

Para adicionar a resposta de Matthew, eu muitas vezes também usam SQL personalizado para fornecer dados iniciais, como documentado aqui .

Django simplesmente procura por arquivos em <app>/sql/<modelname>.sqle executa-los após a criação de tabelas durante syncdbou sqlreset. Eu uso SQL personalizada quando eu preciso fazer algo como preencher minhas tabelas Django de outras tabelas do banco de dados não-Django.

Respondeu 31/01/2009 em 03:43
fonte usuário

votos
1

Pessoalmente meu db de desenvolvimento é para um projeto que estou trabalhando agora é bastante grande, então eu uso dmigrations para criar scripts de migração db para modificar o db (em vez de aniquilar a toda db como eu fiz no início).

Edit: Na verdade, estou usando o Sul agora :-)

Respondeu 31/01/2009 em 03:48
fonte usuário

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