search

splor-mg / cookiecutter-datapackage

https://splor-mg.github.io/cookiecutter-datapackage/dev
0 stars 0 forks source link

Armazenamento de metadados gerados durante pipeline de dados #37

Closed labanca closed 8 months ago

labanca commented 8 months ago

closes #31 closes #36

fjuniorr commented 8 months ago

A parte do scripts/build.py é isso mesmo.

Pra registro, inicialmente eu tinha falado pra gente salvar os metadados customizados na raiz de cada recurso e não na propriedade metadata. Mas @labanca observou bem que como esses metadados são opcionais e não vão existir em todos os recursos, diferentemente do que acontece com o update_at na raiz do data package, é uma forma conveniente de "bater o olho" e ver se existem metadados opcionais que estão sendo inseridos durante a etapa de build.

Um problema de fluxo que não vejo solução e podemos deixar do jeito que está é que alterações no arquivos de log não vão gerar uma nova etapa do make build porque não estão no Makefile.

write_dict_to_json e add_metadata_to_json

Aqui vejo duas questões:

  1. Eu consigo ver a utilidade de facilitar a escrita/leitura de json, mas pra facilitar o reuso nos projetos acho melhor colocar elas no dpm do que como scripts aqui no cookiecutter.
  2. Em termos da API você não prefere um par read_json(path: Path) e write_json(data: dict, path: Path) e as outras manipulações ficam no próprio script de ETL?
labanca commented 8 months ago

2. Em termos da API você não prefere um par read_json(path: Path) e write_json(data: dict, path: Path) e as outras manipulações ficam no próprio script de ETL?

Creio que não entendi o que foi sugerido aqui. Eu fiz duas funções pensando no uso simplificado para o usuário mesmo. Ele não precisar se preocupar com manipulações e somente criar o dicionário ou o par chave:valor que ele quer inserir no json para uma resource específica. Você está sugerindo ter um tipo de função que lida somente com dicionários?

Quando a read_json(path: Path) seria criar uma função no DPM para ler json e retornar um dicionário?

fjuniorr commented 8 months ago

Creio que não entendi o que foi sugerido aqui. Eu fiz duas funções pensando no uso simplificado para o usuário mesmo. Ele não precisar se preocupar com manipulações e somente criar o dicionário ou o par chave:valor que ele quer inserir no json para uma resource específica. Você está sugerindo ter um tipo de função que lida somente com dicionários?

Quando a read_json(path: Path) seria criar uma função no DPM para ler json e retornar um dicionário?

Pode fazer merge deste PR e a gente continua a discussão dessas aqui em um PR no DPM.

Acho que vai ser bom a gente ter que efetivamente salvar JSON no fluxo de ETL pra mostrar quais funções vão ser mais convenientes.