Criar lógica de atualização de última data de `temporal_coverage`.

[rdahis]

Contexto

Hoje temos um problema: quando vira o ano temos que atualizar na mão o limite superior do campo temporal_coverage para todos os recursos atualizados periodicamente (ex: bdm_table, external_link). Exemplo: atualizar 2004(1)2020 para 2004(1)2021. Isso já é inviável hoje, e fica cada vez mais conforme o número de conjuntos no banco cresce.

Proposta

• Back-end

  • Substituir campo update_frequency por is_periodically_updated (ou algo assim) tomando valores yes e no.
  • Definir lag como número de unidades temporais de atraso da atualização. Ex: 10 dias, 1 mês, 1 ano.
  • Para recursos atualizados periodicamente, deixar o limite superior vazio e preencher de acordo com a frequência de atualização. Exemplo: deixar 2004(1).
  • Para recursos não-atualizados periodicamente, preencher o limite superior com a última data de atualização.

• Front-end

  • Para recursos mantidos, inferir limite superior UB de temporal_coverage a partir do intervalo médio/mediano/modal entre anos da cobertura. Exibir UB - lag.

• Exemplos para data atual 2022-01-31:

  • lag=1, 2008(1) ==> 2008 - 2021
  • lag=2, 2008-08(2) ==> 2008-08 - 2021-08
  • Censo: is_periodically_updated='no', 1980, 1991, 2000, 2010 ==> 1980 - 2010

[fernandascovino]

@rdahis a unica mudanca aqui de. FE é mostrar mes/dia/etc adicional ao ano nao? nao sei se entendi o que voce colocou

[rdahis]

@rdahis a unica mudanca aqui de. FE é mostrar mes/dia/etc adicional ao ano nao? nao sei se entendi o que voce colocou

Tem uma parte de FE sim, numas funções lá de getTemporalCoverage. Mas relaxa, estou amadurecendo essa ideia e eu mesmo implemento quando chegar a hora.

[rdahis]

Ver discussão no #414 sobre a necessidade ou não de criar o campo is_periodically_updated ou não.

[AldemirLucas]

@rdahis UpdateFrequency ja vai supri isso correto?

[rdahis]

@rdahis UpdateFrequency ja vai supri isso correto?

Não... Mas bem lembrado, vou tentar já incluir esse issue no novo modelo de dados.

[rdahis]

Discussão continua pós https://github.com/basedosdados/backend/pull/67.

---

Requirements:

• different raw data updates and our table update
• lag between current date and latest update (raw data, table)
  • possibly at different update intervals
• lower classes inherit latest_available if empty: table -> column -> key

---

Validations to include:

• [ ] if any end_* filled out, has to fill out the analogous ones as start_*
• [ ] coverage.entity < update_frequency.entity

---

BE logic

last: datetime

• raw_data_source/information_request: manual or automatic
• table: automatic (from data PR approval)

year > semester > quarter > month > day > hour > minute > second

def datetime_entity(datetime_range):
    if (datetime_range.start_second or datetime_range.end_second):
        return second
    if (datetime_range.start_minute or datetime_range.end_minute):
        return minute
    if (datetime_range.start_hour or datetime_range.end_hour):
        return hour
    if (datetime_range.start_day or datetime_range.end_day):
        return day
    if (datetime_range.start_month or datetime_range.end_month):
        return month
    if (datetime_range.start_quarter or datetime_range.end_quarter):
        return quarter
    if (datetime_range.start_semester or datetime_range.end_semester):
        return semester
    if (datetime_range.start_year or datetime_range.end_year):
        return year

FE / search logic

def latest_datetime_available():
	
    if end_*:
        return end_*
    else:
        if datetime_entity(datetime_range) == update_frequency.entity):
            return <entity>(current_datetime) - update_frequency.lag/coverage.interval
        else:
            if updating.last:
                <entity>(last_updated)
                return <entity>(current_datetime) - update_frequency.lag/coverage.interval

---

Cases to study

case 1:

• update
  • entity: year
  • frequency: 1
  • lag: 1
  • last: 2022-06
• coverage: 2010-02

current: 2023-03 latest: 2022-05 inferred_next_update: 2023-06

case 2:

• update
  • entity: year
  • frequency: 1
  • lag: 1
  • last:
• coverage: 2010-02 -

current: 2023-03 inferred_latest_lower_bound: 2021-02 inferred_latest_upper_bound: 2022-02 inferred_next_update_lower_bound: 2023-06 inferred_next_update_upper_bound: 2023-06

if not last and diff entity, not sure between 0-12 months (or calculated total number of )