turicas
Aceitar nomes de municípios com diferenças de caixa/acentos e alternativos
Nomes de municípios como "sao paulo", "SAO PAULO", "SÃO PAULO", "sao-paulo" devem ser aceitos nas planilhas e corrigidos para "São Paulo". Além disso, nomes como "Gouvêa" devem ser aceitos e convertidos para "Gouveia" (MG). O primeiro caso pode ser facilmente resolvido a partir dessa lógica, já o segundo deve utilizar essa planilha para baixar os nomes alternativos e corrigí-los (lembrar de deixá-la no cache - ver instruções de preenchimento no comentário da célula "nomes alternativos").
Além de corrigir o nome (antes de mostrar erro para quem subiu a planilha), o PR para fechar essa issue deve:
- Se não conseguir baixar a planilha de nomes alternativos, não dar erro (só não usar a estratégia de nomes alternativos e tentar novamente numa outra ocasião)
- Alterar o form de StateSpreadsheet no Django Admin, adicionando uma mensagem explicitando que não é necessário que os nomes estejam de acordo com o valor "canônico" e linkando para a planilha de nomes alternativos (sugerindo adicionar nomes lá que não podem ser automaticamente corrigidos).
@turicas o melhor é mesmo darmos essa volta aí da planilha de nomes alternativos? Não rola um model no Django não? Po, iria facilitar muito o rolê de código, não ter que ficar lidando com cache nem nada. Sei lá, me parece overkill.
Poderíamos deixar esse modelo até dentro da app da covid19 a princípio para não sujar o core do brasil.io.
Do tipo, pra mim o principal problema é exatamente o que ficou entre parêntreses aqui:
(só não usar a estratégia de nomes alternativos e tentar novamente numa outra ocasião)
Ter um base de dados externa pra além do que já temos envolve ficar lidando com esse tipo de questão. O código tende a ficar mais complexo por uma questão de infraestrutura só. Minha sugestão é:
- Podemos colocar pros colaboradores editarem essa planilha;
- Criamos um model que seja um espelho dessa planilha no banco;
- Criamos um management command do django para atualizar o banco com essa planilha;
- Ou colocamos esse comando para rodar no cron ou no processo de release ou deixamos um botão na interface pra admins forçarem o sync;
Mas sei lá, fazer o código depender da planilha é pedir pra termos mais dor de cabeça debugando erros de rede.
Você tem razão. É mais uma "parte móvel" e atrapalha o processo de desenvolvimento e depuração. Acho que podemos então ter um model e nem ter esse management command - podemos dar permissão de escrita a alguns voluntários, que ficarão com responsáveis por manter esse model.
De qualquer forma, antes de buscar por nomes alternativos deveríamos testar o método de slug que é usado no repositório covid19-br para corrigir os nomes dos municípios. Pensando aqui: talvez seja melhor pegarmos o CSV de municípios do IBGE e importá-lo num model, já com os slugs, daí os voluntários vão só adicionando os nomes alternativos. Seria algo como:
class BrazilianCity(models.Model):
state_acryonym = CharField(max_length=2, blank=False, null=False)
city = CharField(max_length=40, blank=False, null=False) # 'Vila Bela da Santíssima Trindade' é a maior, com 32 chars
city_slug = CharField(max_length=40, blank=False, null=False) # essa poderia ser gerada automaticamente
alternative_names_slug = ArraField(CharField(...), blank=True, null=True) # TODO: implementar corretamente -- seria legal passar a função slug em cada item do array antes de salvar pra ter certeza de que é um slug
state_ibge_code = models.SmallIntegerField(blank=False, null=False)
city_ibge_code = models.IntegerField(blank=False, null=False)
estimated_population = models.IntegerField(blank=False, null=False)
Ah, acho que vale fazermos uma limpeza antes de salvar para:
- Rodar a rotina de "limpeza" usada no covid19-br (acho que não é só a função slug, é algo um pouco a mais que isso, se não me engano tem algum parâmetro ou algo assim)
- Não repetir slugs no
ArrayField - Remover slug do
ArrayFieldque seja igual ao camposlugdesse mesmo registro