Spike: Cómo modificar la lógica de los flags para habilitar corridas más frecuentes

[abenassi]

Contexto

Actualmente los flags muestran el último estado conocido de los modelos vs. el anterior, lo que hace que indicadores como "UPDATED" dejen de tener sentido si se aumentara demasiado la frecuencia de corrida.

Un reporte diario que mire estos indicadores mostraría casi siempre que respecto de la última corrida las entidades están UPDATE = True.

Propuesta

Elaborar distintas propuestas alternativas para manejar los flags preservando los dos objetivos:

• Una visión actualizada y real sobre el estado actual de la red de nodos

• Elementos para un reporting "diario" de los cambios de la red de nodos, que faciliten al máximo la implementación de ese reporte

Para esto pensar:

• ¿Qué flags o indicadores pierden sentido si la corrida se hace muy frecuentemente (más que diaria)?. Tal vez es sólo el UPDATED, mientras que el resto funciona bien.

• ¿Cómo se puede preservar una visión "horaria" y "diaria" de los cambios en la red de nodos?. Tal vez UPDATED es un flag configurable, donde el usuario administrador en Django setea cuál es el "lapso de tiempo mínimo" para dejar de considerar un dataset updated, cuando la comparación de hashes arroja que no hubo ningún cambio.