Alterar a lógica dos atributos de datas resolveria alguns problemas de integração?

[trevineju]

Está aumentando o número de casos em que o mesmo site tem diários de período diferentes. A PR #1152 é um bom exemplo disso. Lá, estão registrados 7 casos em que a prefeitura usa um site publicador de forma intermitente: usa pela primeira vez, para de usar, volta a usar. Aparentemente por passar a contratar outro serviço por um tempo.

A questão é que, pelos atuais procedimentos de desenvolvimento adotados no repositório, a integração de uma situação dessa demandaria 3 raspadores. Por exemplo:

raspador	fonte	período	situação
uf_mun_2000	DOEM	2000 a 2009	fica aguardando integração do 2009 em diante
uf_mun_2010	SAI	2009 a 2015	fica aguardando integração do 2015 em diante
uf_mun_2015	DOEM	2015 até hoje	integrado primeiro

Destaco que a questão aqui tem a ver com a fonte DOEM ser a mesma. Se fossem 3 fontes diferentes, seguiria com 3 raspadores.

Uma possibilidade é a de alterar como estamos encarando o start_date e, consequentemente o end_date também, para receber uma lista de pares inicio-fim (tuplas de intervalos). Algo como:

• raspador que só tem o intervalo atual

  # não tem data final pois é vigente
  period = [ ( data de inicio, ) ]  

• raspador descontinuado (no exemplo acima, seria o raspador para o período que está no SAI)

  period = [ ( 2009-mm-dd, 2015-mm-dd ) ] 

• raspador intermitente (no exemplo acima, seria o raspador para DOEM)

  # um intervalo no passado, e um no presente sem final pois é vigente
  period = [ ( 2000-mm-dd, 2009-mm-dd ), ( 2015-mm-dd, ) ]  

Esta proposta busca equilibrar interesses:

1. reduzir a quantidade de arquivos de raspadores do repositório, em especial quando a fonte seria a mesma, que não precisaria de outro raspador
2. mantem raspadores fazendo requisições de forma responsável, não requisitando intervalos - por vezes longos, de anos - que sabemos não ter diários pelo sistema ter migrado.
3. Transparecer (= os intervalos ficam explícitos no código) e viabilizar (=visto que hoje estão sendo postergados) a integração de forma mais prática desses intervalos anteriores
4. A médio prazo, facilitará nossa manutenção de municípios que ficam migrando de sistemas e deixando intervalos legados.

Entretanto, ela é delicada por:

1. Precisaria alterar o BaseGazetteSpider para validar datas desse novo jeito.
2. Impactaria todos os raspadores do repositório, que precisariam ser ajustados para se adequar. Visto que a maior parte é sistema replicável, atualizar as bases e refletir nos raspadores replicados pode ser resolvido mais rápido, mas os demais precisariam de atualizações um a um.

Alguém tem opiniões? Seja na ideia, no impacto, como viabilizar ou resolver de outra forma?