#465 - Gerando dump com comando python dumpdata em json

[lopes05]

Utilizamos o comando dumpdata do django para fazer o dump em json, caso queiram testar fora do ambiente de produção, utilizar o comando:

sudo docker-compose exec django python manage.py runcrons cron.jobs.DbDumperJob --force

Co-authored-by: Felipe Osório [email protected]
Co-authored-by: Harrison Pedro [email protected]

[coveralls]

Pull Request Test Coverage Report for Build 981

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 82.054%

---

Totals
Change from base Build 978:	0.0%
Covered Lines:	3923
Relevant Lines:	4781

---

💛 - Coveralls

[diraol]

Pessoal, vi que vocês estão usando o comando dumpdata, mas sem passar nenhum dos parâmetro que ele permite usar.
Gostaria de pedir a vocês que olhassem os parâmetros existentes na documentação [1] e avaliassem qual devemos usar, qual não devemos usar e os motivos. "Batendo o olho", parece que, pelo nosso modelo de dados, talvez não seja uma boa usar o "default" (mas posso estar completamente enganado, ainda não consegui testar o fluxo de dump e load com a modificação deste PR de vocês).

Vocês chegaram a fazer o dump e o load da base, com dados carregados, para ver se tudo funcionava direitinho?

[1] https://docs.djangoproject.com/en/2.0/ref/django-admin/#dumpdata

[diraol]

Aliás, aproveitando, caso vocês alterem o código, gostaria de pedir que removam a classe duplicada que está no source (sei que não foram vocês que adicionaram a duplicação, mas se perceberem esse tipo de melhoria que pode ser feita não "se avexem" em fazê-la!)

[lopes05]

Já retiramos a classe duplicada, vamos dar uma olhada na documentação para utilização de possíveis parâmetros.

[leonardofl]

Ops, malz pela classe duplicada!

Mas acho q essa estratégia de gerar o dump como um json do Django não é uma boa.

[O pessoal da UnB não tinha como saber, mas] um dos objetivos do dump é permitir que outras pessoas possam importar o banco em suas máquinas e explorar os dados com SQL. Já é muito pedir pra que usem o PostgreSQL (idealmente o dump deveria ser um SQL padrão, importável em qualquer banco SQL), mas fazer com que a reimportação dependa do Python/Django aí piora a situação.

Talvez isso possa ser rebatido com algo tipo "oh, mas é fácil importar json -> banco usando XYZ", mas aí teríamos que saber isso e incluir essas instruções na página http://radarparlamentar.polignu.org/dados/downloads/. Mas a princípio defendo que o dump continue sendo em formato SQL.

[lopes05]

Ok, vamos pensar na estratégia de manter o SQL então.

[diraol]

@leonardofl acho que vale usar o dump em json e depois só convertê-lo para o formato que queremos.

Podemos usar o CSVKit para fazer as transformações desejadas.
(json -> csv; csv -> sql; -> csv -> postgesql)

Independente disso, acho que precisamos definir quais dados queremos exportados e "em que formato" (no sentido de: queremos tabelas de relacionamento? Queremos PKs? etc).

[leonardofl]

Quais dados: todas das tabelas com prefixo "modelagem".

Em q formato: por mim, sql, mantendo chaves primárias, relacionamentos etc (constrains não são necessárias).

[lopes05]

Para podermos gerar um arquivo SQL, acho que vai ser necessário ter o postgres no container base, para podermos assim usar o pg_dump e de alguma forma contornar o erro antigo que foi relatado na issue.

[lopes05]

Modifiquei para criar com o comando pg_dump e SQL nesse último commit, pelo que testei está tudo OK.

[lopes05]

Opa, faltou um arquivo, assim que tiver internet subo!