Problemas com contenttypes ao carregar um acessório em Django

votos
90

Estou tendo problemas para carregar dispositivos elétricos Django no meu banco de dados MySQL por causa do ContentTypes conflitos. Primeiro eu tentei despejar os dados de apenas meu aplicativo como este:

./manage.py dumpdata escola > fixture.json

mas eu continuei recebendo faltando problemas de chave estrangeira, porque meu app escola utiliza tabelas de outros aplicativos. Eu mantive a adição de aplicativos adicionais até que cheguei a esta:

./manage.py dumpdata contenttypes auth escola > fixture.json

Agora o problema é o seguinte violação de restrição quando eu tento carregar os dados como um dispositivo de ensaio:

IntegrityError: (1062, Duplicate entry 'escola-t23aluno' for key 2)

Parece que o problema é que o Django está tentando recriar dinamicamente contenttypes com diferentes valores de chave primária que entram em conflito com os valores de chave primária do equipamento. Este parece ser o mesmo que bug documentado aqui: http://code.djangoproject.com/ticket/7052

O problema é que a solução recomendada é para despejar o aplicativo contenttypes que eu já estou fazendo !? O que da? Se faz alguma diferença que eu tenho algumas permissões modelo personalizado como documentado aqui: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

Publicado 12/05/2009 em 18:02
fonte usuário
Em outras línguas...                            


12 respostas

votos
126

manage.py dumpdata --naturalusará uma representação mais durável das chaves estrangeiras. No Django eles são chamados de "chaves naturais". Por exemplo:

  • Permission.codename é usado em favor de Permission.id
  • User.username é usado em favor de User.id

Leia mais: chaves naturais seção "serialização de objetos Django"

Alguns outros argumentos úteis para dumpdata:

  • --indent=4 torná-lo legível.
  • -e sessions excluir dados de sessão
  • -e admin excluir histórico de ações de administração no local de administração
  • -e contenttypes -e auth.Permissionexcluir objetos que são recriados automaticamente a partir do esquema de cada vez durante syncdb. Só use-o em conjunto com --natural, ou então você pode acabar com números de identificação mal alinhados.
Respondeu 02/11/2010 em 09:17
fonte usuário

votos
33

Sim, isso é realmente irritante. Por um tempo eu trabalhei em torno dele, fazendo uma "reinicialização manage.py" no aplicativo contenttypes antes de carregar o dispositivo elétrico (para se livrar dos dados ContentTypes gerados automaticamente que diferem da versão despejado). Isso funcionou, mas eventualmente eu fiquei doente dos aborrecimentos e abandonadas luminárias totalmente em favor de dumps SQL retas (claro, então você perde portabilidade DB).

atualização - a melhor resposta é usar a --naturalbandeira para dumpdata, como observado em uma resposta abaixo. Essa bandeira ainda não existia quando escrevi essa resposta.

Respondeu 13/05/2009 em 01:58
fonte usuário

votos
28

Tente pular contenttypes ao criar dispositivo elétrico:

./manage.py dumpdata --exclude contenttypes > fixture.json

Ela trabalhou para mim em uma situação similar para testes de unidade, a sua visão sobre os contenttypes realmente ajudou!

Respondeu 30/05/2010 em 04:03
fonte usuário

votos
13

As respostas aqui todos os antigos ... A partir de 2017, a melhor resposta é:

manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission --indent 4
Respondeu 05/05/2017 em 12:41
fonte usuário

votos
10

Eu resolvi este problema em meus casos de teste, redefinindo o aplicativo contenttypes do teste de unidade antes de carregar o meu arquivo de despejo. Carl sugeriu este já usando o manage.pycomando e eu fazer a mesma coisa usando apenas o call_commandmétodo:

>>> from django.core import management
>>> management.call_command("flush", verbosity=0, interactive=False)
>>> management.call_command("reset", "contenttypes", verbosity=0, interactive=False)
>>> management.call_command("loaddata", "full_test_data.json", verbosity=0)

Meu full_test_data.jsondispositivo elétrico contém o despejo aplicativo contenttypes que corresponde ao resto dos dados de teste. Redefinindo o aplicativo antes do carregamento, que impede a cópia da chave IntegrityError.

Respondeu 04/10/2010 em 14:41
fonte usuário

votos
9

Eu não estava usando o MySQL, mas em vez de importar alguns dados de um servidor ao vivo em sqlite. Limpar os contenttypesdados de aplicativos antes de executar loaddatafez o truque:

from django.contrib.contenttypes.models import ContentType
ContentType.objects.all().delete()
quit()

E depois

python manage.py loaddata data.json
Respondeu 12/11/2016 em 00:33
fonte usuário

votos
2
python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth.Permission --exclude=admin.logentry --exclude=sessions.session --indent 4 > initial_data.json

Isso funciona para mim. Aqui estou excluindo tudo bubt os modelos reais.

  • Se você ver qualquer outro modelo diferente dos modelos que você criou você pode excluir com segurança os. Uma desvantagem dessa abordagem é que desligares na dados de registro, bem como dados de autenticação.
Respondeu 21/06/2017 em 01:51
fonte usuário

votos
1

Eu tinha encontrado erro semelhante às vezes atrás. Descobriu-se que eu estava tentando carregar os equipamentos antes de criar as tabelas necessárias. Então eu fiz:

$ python manage.py makemigrations
$ python manage.py migrate
$ python manage.py loaddata fixtures/initial_data.json

e funcionou perfeitamente

Respondeu 05/07/2016 em 14:28
fonte usuário

votos
1

É muito, muito chato .. Eu mordido por isso a cada momento.

Tentei dumpdata com contenttypes --exclude e --natural, eu sempre chegar problemas ..

O que funciona melhor para mim é simplesmente fazer um truncate table django_content_type;após o syncdb e depois carregar os dados.

É claro que para carregamento automático initial_data.json você está fallball.

Respondeu 14/10/2011 em 15:14
fonte usuário

votos
1

Vou dar outra resposta possível que eu só descobri. Talvez ele vai ajudar o OP, talvez ele vai ajudar alguém.

Eu tenho uma tabela de relacionamento muitos-para-muitos. Ele tem uma chave primária e as duas chaves estrangeiras para outras tabelas. Descobri que se eu tiver uma entrada no dispositivo cujas duas chaves estrangeiras são os mesmos que outra entrada já na mesa com um diferente pk, ele irá falhar. M2M tabelas de relacionamento têm um "único conjunto" para as duas chaves estrangeiras.

Então, se é um relacionamento M2M que está quebrando, olhar para as chaves estrangeiras que está adicionando, olhar para o seu banco de dados para ver se esse par de FKs já estão listados sob uma PK diferente.

Respondeu 06/10/2011 em 23:42
fonte usuário

votos
0

Você precisa usar chaves naturais para representar quaisquer relações de chave e muitos-para-muitos estrangeiros. Além disso, pode ser uma boa idéia para excluir a sessiontabela no sessionsaplicativo, ea logentrytabela no adminaplicativo.

Django 1.7+

python manage.py dumpdata --natural-foreign --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json

Django <1,7

python manage.py dumpdata --natural --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json

De acordo com a documentação do Django , --naturalfoi reprovada na versão 1.7, então a opção --natural-foreigndeve ser usada.

Você também pode omitir a chave primária nos dados serializados deste objeto, uma vez que pode ser calculado durante a desserialização, passando a --natural-primarybandeira.

python manage.py dumpdata --natural-foreign --natural-primary --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json
Respondeu 07/12/2018 em 04:02
fonte usuário

votos
0
./manage.py dumpdata app.Model --natural-foreign

vai mudar

  "content_type": 123

para

  "content_type": [
    "app_label",
    "model"
  ],

E dispositivo elétrico funciona para TestCaseagora

Respondeu 25/01/2018 em 10:27
fonte usuário

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