[DATA] Navire amarré hors des ports en base

[marthevienne]

Le Gérard Luc IV est amarré depuis 44 jours dans une AMP dans un port qui n'est pas un port de pêche => il est premier dans le ranking sur le dashboard donc c'est problématique.

=> Court terme :

• retirer l'AMP en question des calculs (côté API uniquement) => c'est une AMP où il n'y a pas de pêche

=> Long terme :

• ajouter le port en question avant recalcul des excursions à venir (?)
• remettre l'AMP (côté API)

[rv2931]

Peut-être rajouter un champ active:true/false au niveau des zones et traiter ça à minima dans l'API
Peut-être rajouter l'info dans la table metrics, comme ça on peut choisir aussi côté API/metrics si on intègre ou pas les zone active/inactive
Mais dans tous les cas il faut recalculer.
En urgence on peut à minima supprimer les données dans la base qui concerne ce bateau sur la période
Tu peux confirmer le endpoints utilisé qui pose souci (vérifier si c'est une requête directement sur les tables ou si c'est sur fct_metrics) ?

[rv2931]

Je te propose d'ajouter un champ enable (PR #382 ) dans dim_zone et de le reporter aussi dans fct_metrics/zone_enable. Tout est à True par défaut. Les calculs ne tiennent pas compte de cette info pour calculer l'activité dans tous les cas comme aujourd'hui, seul les requêtes d'aggrégation la prenne en compte notamment pour les réponses API.
J'ai pas pu tester non plus, vu que j'ai supprimé les stats metrics et pas eu le courage de recharger un dump
Je te laisse tester et valider (il y a deux requêtes à passer une fois la migration passée pour désactiver la zone en question dans dim_zone et fct_metrics historique)

[rv2931]

Concernant le endpoint /vessels/{vessel_id}/times-in-zones j'ai aussi corrigé une erreur de requête
le select from était bien sur Metrics mais il y avait des filtres sur Zone sans qu'il y a de JOIN explicite sur la table dim_zone
Dans ce cas, sql_alchemy rajoute automatiquement dim_zone dans le from mais comme il n'y a pas de relation explicite, les zone sont ajoutées un peu "on sait pas trop comment". Globalement j'avais une retour API qui me donnait un temps passé dans la zone de 19 années et 89 jours alors que la zone étant désactivée (enable=false) on devait trouver aucune activité dans la zone et donc une chaîne vide. C'est corrigé et vérifié du coup
La requête que ça donne c'est ça avec un from fct_metrics, dim_zone sans join

SELECT fct_metrics.vessel_id, fct_metrics.zone_id, fct_metrics.zone_name, fct_metrics.zone_category, fct_metrics.zone_sub_category, sum(fct_metrics.duration_total) AS duration_total, sum(fct_metrics.duration_fishing) AS duration_fishing 
FROM fct_metrics, dim_zone 
WHERE fct_metrics.vessel_id = 412 AND dim_zone.enable = true AND fct_metrics.timestamp BETWEEN '2024-10-10 23:42:58.336610' AND '2024-12-17 23:42:58.336673' AND fct_metrics.zone_category = 'amp'
GROUP BY fct_metrics.vessel_id, fct_metrics.zone_id, fct_metrics.zone_name, fct_metrics.zone_category, fct_metrics.zone_sub_category
ORDER BY duration_total DESC

or la 'bonne' requete c'est ça:

SELECT fct_metrics.vessel_id, fct_metrics.zone_id, fct_metrics.zone_name, fct_metrics.zone_category, fct_metrics.zone_sub_category, sum(fct_metrics.duration_total) AS duration_total, sum(fct_metrics.duration_fishing) AS duration_fishing 
FROM fct_metrics
JOIN dim_zone ON dim_zone.id = fct_metrics.zone_id
WHERE fct_metrics.vessel_id = 412 AND dim_zone.enable = true AND fct_metrics.timestamp BETWEEN '2024-10-10 23:42:58.336610' AND '2024-12-17 23:42:58.336673' AND fct_metrics.zone_category = 'amp'
GROUP BY fct_metrics.vessel_id, fct_metrics.zone_id, fct_metrics.zone_name, fct_metrics.zone_category, fct_metrics.zone_sub_category
ORDER BY duration_total DESC

[marthevienne]

Merci ! Je vais regarder ta PR et merci d'avoir trouvé l'erreur pour #370 :)