quand on supprime un jdd sur transport, est-ce qu'on conserve les fichiers GTFS historiques qu'on avait conservé ou bien ils sont purgés ?
Je connais mal cette partie de l'application, donc je prends quelques notes ici pour créer une doc et partager.
Réponse à la question de @NicolasBerthelot
A priori je ne vois rien dans le code de l'application qui supprime les ressources historisées. Voir le détail ci-dessous.
Cela n'empêche pas une suppression par d'autres mécanismes (cela peut exister, exemple: "règles lifecycle" pour supprimer après un certain temps), mais à ma connaissance ce type de mécanisme n'est pas activé sur les buckets S3.
Stockage
L'application transport utilise un stockage "compatible Amazon S3", fourni par CleverCloud:
Pour les non techniques, c'est une sorte de disque dur interrogeable par API.
Les données sont actuellement lisibles en public sans restriction (il faudrait faire attention à la consommation associée, mais elle ne semble pas poser problème actuellement).
Parcours des ressources en base de données, ayant un format "GTFS" ou "NeTEx", une url et un titre, et n'étant pas marquées "community resource" (ce qui exclut nos conversions)
Création d'un bucket (???) par resource ? (à vérifier et documenter)
Vérification du besoin "d'updater le backup" (via comparaison meta-data)
Re-récupération de la donnée depuis sa source et envoi vers le "cellar S3"
Un lancement de la couverture de test semble montrer que ce code n'est pas testé.
Il y a des logs d'imports mais pas de remontée autre, il faudra vérifier.
Lorsqu'un affiche une page dataset, les ressources sont ensuite récupérées et affichées comme un listing via ce code:
NicolasBerthelot
commented
2 years ago
Suite à question @NicolasBerthelot:
Je connais mal cette partie de l'application, donc je prends quelques notes ici pour créer une doc et partager.
Réponse à la question de @NicolasBerthelot
A priori je ne vois rien dans le code de l'application qui supprime les ressources historisées. Voir le détail ci-dessous.
Cela n'empêche pas une suppression par d'autres mécanismes (cela peut exister, exemple: "règles lifecycle" pour supprimer après un certain temps), mais à ma connaissance ce type de mécanisme n'est pas activé sur les buckets S3.
Stockage
L'application transport utilise un stockage "compatible Amazon S3", fourni par CleverCloud:
https://www.clever-cloud.com/doc/deploy/addon/cellar/
Pour les non techniques, c'est une sorte de disque dur interrogeable par API.
Les données sont actuellement lisibles en public sans restriction (il faudrait faire attention à la consommation associée, mais elle ne semble pas poser problème actuellement).
Zones de code identifiées
Un job est lancé une fois par jour ici:
https://github.com/etalab/transport-site/blob/98a2f69981dc6c8d48879da6698b9301931f11e1/config/prod.exs#L20-L21
Le code de ce job est ici:
https://github.com/etalab/transport-site/blob/54975862480234d9d3fb8e6c7cc98dfe7f31a995/apps/transport/lib/transport/history.ex
L'algorithme semble être:
Un lancement de la couverture de test semble montrer que ce code n'est pas testé.
Il y a des logs d'imports mais pas de remontée autre, il faudra vérifier.
Lorsqu'un affiche une page dataset, les ressources sont ensuite récupérées et affichées comme un listing via ce code:
https://github.com/etalab/transport-site/blob/98a2f69981dc6c8d48879da6698b9301931f11e1/apps/db/lib/db/dataset.ex#L578
Actions à prévoir