feat: cria novo campo em coluna para automatizar update em pipelines

[laura-l-amaral]

Resumo:

Add date coverage reference: para que a gente consiga saber como descobrir a cobertura temporal da tabela apenas usando os metadados que estão no django

---

Detalhamento Hoje em dia o lag de bdpro é passado hard coded no código de cada pipeline. Isso significa que para cada pipeline precisamos preencher os parametros da task de update_metadata (imagem).

Como reformulei o flow que materializa as tabelas no BQ para incluir download o csv que será dispnibilizado para o usuário, queria aproveitar e colocar essa task que atualiza os metadados junto. Assim a gente garantiria que toda vez que uma tabela fosse atualizada, os metadados também atualizariam logo em seguida.

O problema é: o único local que temos as informações necessárias para atualizar os metadados é o próprio código de pipeline, não temos em nenhum lugar no backend todas as informações necessarias para aplicar esse lag (nos dados e no backend).

Atualmente temos o seguinte campos nessa task que não tem nenhuma correspondência com o backend:

- date_column_name: Um dicionário especificando a unidade temporal e nome das colunas usadas para extrair a cobertura temporal. 
  Aceita como chaves do dicionario :
    {"year", "month"}, 
    {"year", "quarter"}, 
    {"date"}
  Usa esse dicionário para saber como combinar colunas para consultar a cobertura temporal dos dados. Exemplo: MAX(DATE(ano_referencia,mes_referencia,1))

Solução proposta:

• Criar um campo para indicar se uma coluna deve ser utilizada para consultar a cobertura temporal da tabela
  • campo chamado date_time_range_column ou coverage_column sendo um menu drop down com as seguintes possibilidades:year,quarter,month,date.

Evidências

https://github.com/basedosdados/backend/assets/5381250/56dad868-098f-4f60-a7d6-7cb589601aa3

[rdahis]

Uma solução mais coesa seria:

• Adicionar o campo datetime_range.unit, que seria uma chave estrangeira para observation_level. As opções de escolha dessa chave seriam só os observation_level cuja entidade seja datetime e que tenha column ligada à mesma tabela.
• Aí, através da conexão table.coverage, podemos criar a propriedade table.datetime_range_unit, que retornaria um column.id.

Observações:

• Isso impõe que o observation_level terá que estar bem preenchido. Acho bom.
• Isso supõe que tabelas com pipelines tem uma coluna de datetime correspondente (a atual solução proposta também). Consigo visualizar casos onde não teria. Por exemplo, uma tabela que seja um "retrato mais atual", tipo a tabela br_me_cnpj.simples. Sabemos que a atualização da pipeline é mensal, mas não tem a coluna mes lá dentro.

[laura-l-amaral]

@rdahis Pelo ponto que vc trouxe nas observações não acho que é uma solução funcional dahis, não é obrigatório que a cobertura temporal esteja no observation level. Exemplo: uma tabela tem como nível de observação uma proposição legislativa. A data de inclusão ou edição dessa proposição é uma caracteristica da proposição, por isso não deve estar no nível de observação. Ao mesmo tempo, é essa data que me informa a cobertura temporal da tabela, tem vários outros exemplos que são assim

[rdahis]

Hmm legal faz sentido. Iterando nisso, que tal então o campo datetime_range.unit ser uma chave estrangeira para column? O resto do argumento e properties fica igual.

[laura-l-amaral]

@rdahis por mim pode ser! conseguimos implementar isso rapido?

[rdahis]

Seguindo no #627.