feat: historisation des task executions

[rv2931]

linked #303
ajout d'une colonne Id et active
pour cela on stock temporairement la table actuelle pour garder les data en la renommant
on crée une nouvelle table avec une primary key sur id + colonne active
on recopie les données de la table renommée vers la nouvelle table
on supprime l'ancienne table renommée
A chaque nouvelle exécution une nouvelle ligne est créé avec l'attribut active=True

[rv2931]

Je pense que ça serait pas mal de rajouté une colonne qui donne le delta avec la dernière requête de même task_name
au moins prévoir la colonne pour le remplir avec un pipleline etl ou bien de le calculer directement via le repository TaskExecution

[marthevienne]

génial Hervé ! Ce serait super d'ajouter le delta. Est-ce qu'on pourrait ajouter d'une certaine manière les delta passés sur la tâche load_spire_ais_data ?

[rv2931]

@marthevienne en regardant spire_ais_data.spire_update_statement j'ai l'impression qu'on seulement les heures de dernière mise à jour des positions et non véritablement l'heure à laquelle notre appli a interrogé l'API spire par contre avec l'heure "spire_ais_data.created_at" on pourrait sûrement supposer que ces données ont été créée par un batch de création de load_spire_ais_data.
Si par contre tout ou partie de ces données elles ont été créées à partir d'un CSV, cette heure là n'a plus trop de sens par contre mais si ce cas existe c'est peut être anecdotique

[rv2931]

Si ça a l'air de le faire, j'ai bien globalement 15 minutes entre chaque bloc de creation donc y aurait moyen

[marthevienne]

Yes, spire_ais_data.created_at nous permet de reconstituer grossièrement les coupures passées sachant que la création des messages AIS en base est hyper rapide (quelques secondes).

[rv2931]

Ok. Après migration on pourra exécuter cette requête SQL qui peuplera la table task_execution à partir des données spire_ais_data déjà existantes
A noter cette requête considère que la requête la plus récente dans les données récupérée est active=True
ça ne pose pas trop de souci car à chaque ligne on remet à active=False toutes les lignes existante et dans le get_point_in_time j'ai modifié le .scalar en .scalar_one_or_none() => le scalar one_or_none partira en erreur si d'aventure 2 lignes se sont retrouvé avec un active=true mais au moins au saura pourquoi et ça ne doit arriver qu'une seule fois dans le pire des cas
On peut exécuter cette requête plusieurs fois sans souci vu qu'elle vérifier que la donnée à insérer n'existe pas déjà dans task_executions sur la base de la valeur spire_ais_data.created_at=task_executions.point_in_time

insert into public.tasks_executions (task_name,point_in_time,created_at,delta,active)
select distinct
'load_spire_data_from_api' as "task_name",
T1.created_at as "point_in_time",
T1.created_at,
T1.created_at-(select distinct created_at from spire_ais_data where created_at < T1.created_at group by created_at order by created_at desc limit 1) as "delta",
case when T1.created_at = (select MAX(created_at) from spire_ais_data) and not EXISTS(select 1 from public.tasks_executions where task_name = 'load_spire_data_from_api' and active = True) then true else false end as "active"
from spire_ais_data T1
where T1.created_at not in (select point_in_time from public.tasks_executions where task_name = 'load_spire_data_from_api')
group by T1.created_at
order by T1.created_at desc

EDIT 02/12/2024 14:33 => rajout ' un test pour mettre active=True exclusivement si il n'y a pas de ligne load_spire_data_from_api avec active=True qui pré existe dans la table public.task_executions (ça évite d'avoir potentiellemnt deux lignes à active=true)

[rv2931]

Je peux voir pour intégrer cette requête a la migration alembic, ça serait plus propre et automatique

[rv2931]

J'ai intégré la récupération et génération de ligne task_execution à la migration alembic
J'ai testé upgrade/downgrade c'est OK pour moi
J'ai pas pu tester l'acquisition Spire vu que j'ai pas le TOKEN mais je suis assez confiant
@marthevienne je te laisse intégrer et déployer si tu valides la solution et l'intérêt

[rv2931]

On obtient ce genre de choses

[marthevienne]

Merci Hervé ! Je checke ça au plus vite.

[rv2931]

Juste au cas où il y a deux PR qui contiennent des révisions alembic (#212 et celle-ci) au moment d'intégrer la seconde selon l'ordre il faudra penser mettre a jour la séquence des révisions dans la deuxième PR intégrée

[marthevienne]

Ok, on va merger celle-là puis la #212