Closed danielfsbarreto closed 4 years ago
Os erros são nas tabelas :
Os schemas que são usados no projeto são mantidos aqui o que acaba criando uma duplicidade, sempre que houver manutenção aí tem que atualizar o datapackage.json
/cc @augusto-herrmann
Pois é, o ideal seria esses esquemas serem gerados a partir do datapackage.json
, e não o contrário.
Pois é, o ideal seria esses esquemas serem gerados a partir do
datapackage.json
, e não o contrário.
cabe uma issue ou PR aí, identificar onde no código tem referência aos schemas/*.csv
, e o datapackage já tá nas dependências do projeto, certamente daria para automatiza isso
Pois é, o ideal seria esses esquemas serem gerados a partir do
datapackage.json
, e não o contrário.
Essa issue aí ainda é outro caminho, diferente do que estamos sugerindo aqui.
Aqui:
datapackage.json
-> esquemas em formato csv
customizado na pasta schema/*.csv
datapackage.json
-> documentação da APILá:
A questão toda passa pelo processo de desenvolvimento. Hoje, quem desenvolve é o @turicas, e parece que ele prefere começar a definir o esquema pelo banco. Enquanto continuar assim, o banco de dados é que teria que ser então o ponto de partida.
certo, então seria desenvolver um script que geraria o datapackage.json
baseado nestes meta-dados, certo ?
Se o datapackage.json
atender à demanda que temos hoje (já explico abaixo), então acho que o ideal seria termos apenas o datapackage.json
no repositório, assim o Brasil.IO poderia consumir desse arquivo e os arquivos schema/*.csv
poderiam ser gerados automaticamente a partir do datapackage.json
(ou, quando a rows
suportar pgimport
e csv2sqlite
com data package, eles poderiam ser deletados).
As demandas atualmente são:
schema/*.csv
)Eu não conheço muito da especificação do datapackage, mas se tiver como embutirmos metadados personalizados (esses do Brasil.IO), então podemos começar um processo de migração (ficará bem melhor se for uniformizado assim :).
@augusto-herrmann você, que conhece mais a especificação do data package, acha que atende a essas necessidades acima? Se sim, vamos criar uma issue no repositório do Brasil.IO para tratar disso?
Sobre a geração de documentação da API: como os metadados precisam ficar armazenados na base do Brasil.IO (e não serão exatamente iguais a esse datapackage.json
que propus, pois nem sempre o dataset estará super atualizado com relação ao repositório), então faz sentido a geração da documentação da API ser feita automaticamente a partir do banco de dados do Brasil.IO e não do (futuro) datapackage.json
.
acho que deveríamos estar discutindo isso lá na issue https://github.com/turicas/brasil.io/issues/204
acho que deveríamos estar discutindo isso lá na issue turicas/brasil.io#204
Concordo. Colei esses meus comentários lá.
Os testes estão dando erro novamente. Reabrir esta issue ou criar uma nova?
Os testes estão dando erro novamente. Reabrir esta issue ou criar uma nova?
cria uma nova
deve ter adicionado campos ou mudado a ordem
Criada #193.
Estava ocorrendo um problema recorrente com a execução da action do
goodtables
do projeto, que foi resolvido em #178. Agora é preciso resolver todas as inconsistências que se acumularam no decorrer desse tempo.Job: https://github.com/turicas/covid19-br/runs/814979053?check_suite_focus=true#step:3:911