419 fix create update segments excursions

[marthevienne]

#419

[marthevienne]

Coucou @rv2931, c'est une pull request non définitive :

• correction d'un certain nombres d'erreurs dans l'ETL (mauvais calcul des durées, coquille dans la logique de calcul des métriques qui gardait en mémoire l'affection de la variable types d'un segment à l'autre)
• refactoring pour fonctionner pas que par slot de temps mais slot de temps x vessel_id (on enlève 1 interaction avec la DB + maintien en vie de la session assurée (même avec traitement de 10 mois de données).

On peut repartir de là pour restructurer l'ETL et permettre le recalcul ou l'insertion de nouvelles positions a posteriori.

[rv2931]

Hello
Désolé pour le délai
Je viens de relire vite fait
As-tu pu tester si ton traitement résout ce souci là #345 . J'ai tendance à penser que oui mais j'ai pas testé (cas où les tables calculées sont vides)
Sinon j'avais remarqué que Spire renvoie les dernières positions des bateaux systématiquement, même si ça fait plusieurs jours/mois qu'il n'y a pas eu de mise à jour, sauf que vu qu'on se base dans un premier temps sur la création de la ligne dans spire_ais_data, on traite quand même systématiquement des positions même si on peut déjà savoir que celles-ci ne vont pas être insérées puisque obsolètes. Dans cette issue je donnais plus d'info: #402

[marthevienne]

Hello @rv2931, j'ai effectivement vu ta proposition de se baser plutôt sur le position_update_timestamp mais j'avoue avoir du mal à comprendre comment tu veux suivre cela pour chaque navire, tu imagines ça comment ?

[rv2931]

Je pense qu'en déliant created_at et updated_at et en reprécisant bien la définition déjà on peut arriver à optimiser certaines choses
Created_at: datetime effective à laquelle la ligne a été ajoutée à la table spire_ais_data
Updated_at: date de dernière mise à jour effective de la position

Si on prend bien position_update_timestamp comme date de mise à jour (enfin de ce que j'ai pu voir) on récupère bien la date effective de la vraie dernière position reçue par spire. Vu que c'est une date UTC qui vient de spire, on a pas non plus le problème de mauvais réglage de l'heure de l'horloge du bateau.

Le fait d'avoir un created_at et updated_at qui disent bien ce qu'ils veulent dire, cela permet pour la suite du traitement que sur un slot entre interval_start et interval_end, on peut éventuellement dans une première étape traiter toute nouvelle position issue de la requête API en se basant sur created_at par contre on peut déjà optimiser sur le fait que la suite du traitement ne traitera que les updated_at qui sont effectivement entre interval_start et interval_end

Ça élimine déjà toutes les requêtes API qui remontent des positions de bateaux qui n'ont pas été mise a jour depuis un certain temps côté spire (arrêt transpondeur, arrêt d'exploitation, ...). En rajoutant une première étape déjà de notre côté on peut aussi en éliminer toutes les positions qui n'ont pas évolué géographiquement depuis un certain temps (transpondeur ON mais bateau au mouillage) et corriger éventuellement ce updated_at a la véritable première position mise a jour avant arrêt bien qu'il répond toujours et que le created_at soit toujours a la date de requête

[marthevienne]

j'ai clos la PR, on peut basculer la discussion vers #427