feat: datetime_range.unit

[rdahis]

Iterando o #621.

• Criar campo datetime_rande.unit como FK para column.
• No campo datetime_rande.unit, exibir só colunas da mesma tabela.
• Criar property table.datetime_range_unit.
• Rodar migrations.

[rdahis]

@jhonylucas74 sabe como colocar um filtro aqui para só aparecer opções de colunas que estejam na tabela (ligada através de table.coverage.datetime_range)? Agora fica pesado esse campo no Django Admin.

[jhonylucas74]

Não tem um jeito fácil nesse caso devido a complexidade das relações do modelo. Uma coisa que daria pra fazer é, se column possuir algum valor, categoria, tipo que vc queria filtrar é fácil de fazer usando o limit_choices_to. Mas se precisar verificar as relações entres as instâncias para trazer com base nas relações é mais complicado. Vai ser necessário um custom form no admin do django.

[jhonylucas74]

Posso tentar ver isso amanhã, testar aqui e se eu tiver sucesso eu mando eu mando as alterações.

[laura-l-amaral]

@jhonylucas74 acho que isso foi aplicado no campo de observation level que está no formulário de coluna do django se precisar ed uma referência. ele só puxa as opções de observation level que estão na mesma tabela

[rdahis]

Aqui:

backend/backend/apps/api/v1/admin.py

Line 109 in 00db381

def formfield_for_foreignkey(self, db_field, request, **kwargs):

[laura-l-amaral]

@rdahis percebi um problema importante com essa implementação que vc sugeriu:
temos mais de uma cobertura temporal para tabelas que são parcialmente BD Pro, como que faz nesses casos? acho que vc só tava imaginando um único datetime range para cada tabela né? Vai ficar com uma mesma coluna conectada a 2 datetime_range? Acaba que fica uma informação duplicada e atrapalha a consulta a api

Qual que era o problema da implementação que eu tinha sugerido?

[rdahis]

@rdahis percebi um problema importante com essa implementação que vc sugeriu: temos mais de uma cobertura temporal para tabelas que são parcialmente BD Pro, como que faz nesses casos? acho que vc só tava imaginando um único datetime range para cada tabela né? Vai ficar com uma mesma coluna conectada a 2 datetime_range? Acaba que fica uma informação duplicada e atrapalha a consulta a api

Não é um problema não. Quando tiver múltiplas coverage, pode ficar a mesma coluna ligada à duas. A property table.datetime_range_unit está pegando a "coluna mais comum" entre datetime_ranges. Na prática é pra ser sempre a mesma, porque diferentes coberturas na mesma tabela deveriam ter todas a mesma unidade temporal.

[laura-l-amaral]

@rdahis Ok entendi, podemos seguir assim. O único "problema" é que equipe dados vai ter que preencher igual nas duas e fica aberto para esquecer ou errar e preencher diferente. Ter que preencher 2 vezes a mesma informação não é uma redundância no nosso modelo? Pra lidar com o problema que eu coloquei ali eu incluo no código uma verificação se caso tiver 2 coberturas, se elas estão ambas preenchidas e se estão iguais.

[rdahis]

É uma certa redundância porque acho que nunca teremos uma tabela com duas unidades temporais diferentes (ex: parte com ano e parte com mes). Mas é isso aí mesmo. Eu deixaria passar sem validação mas vou tentar implementar aqui.

Se for crítico para a feature de tradução de tabelas, vamos aprovar logo e adicionar a validação depois? @laura-l-amaral

[laura-l-amaral]

@rdahis não é crítico não pra tradução, é pra gente melhorar o sistema de atualização de metadados só. Ficar mais automático e reduzir os casos que os metadados ficam diferentes dos dados

[rdahis]

Adicionei a validação. Testei local via backend do Django e ele apresenta uma barra de erro quando eu tento adicionar uma segunda unit diferente da primeira. Vejam abaixo. Ele só mostra essa barra vermelha, mas não exibe a mensagem exatamente do erro, que é "Datetime range units do not refer all to the same column.".

De qualquer jeito, seria bom @laura-l-amaral e @jhonylucas74 testarem local antes de aprovar.

[rdahis]

Ainda está aberta essa questão de exibir o erro corretamente no Django. Mas vou dar merge para começarmos a preencher.

[rdahis]

Parece que o deploy não foi. Sabe onde vejo os logs? @jhonylucas74 @gabriel-milan