Optimisation des téléchargements (md5)

[tgrandje]

Ajouter un contrôle du md5 avant de lancer un téléchargement

[tgrandje]

r = requests.Session()
url = "https://wxs.ign.fr/x02uy2aiwjo9bm8ce5plwqmr/telechargement/prepackage/ADMINEXPRESS_SHP_TERRITOIRES_PACK_2023-02-16$ADMIN-EXPRESS_3-1__SHP_LAMB93_FXX_2023-02-16/file/ADMIN-EXPRESS_3-1__SHP_LAMB93_FXX_2023-02-16.7z"
r = s.get(url, stream=True)
print(r.headers['content-md5'])

[linogaliana]

ça semble prometteur:

import os
import requests
from cartiflette.download import create_url_adminexpress, get_vectorfile_ign

url = create_url_adminexpress(
        provider="IGN", year=2022, source="EXPRESS-COG-TERRITOIRE", field="reunion"
    )

r = requests.Session()
r = r.get(url, stream=True)
md5 = r.headers['content-md5']

get_vectorfile_ign(
    provider="IGN", year=2022, source="EXPRESS-COG-TERRITOIRE", field="reunion"
)

filename = [path for path in os.listdir("/tmp") if path.endswith(".7z")]

hashlib.md5(open(f"/tmp/{filename[0]}",'rb').read()).hexdigest() == r.headers['content-md5'] #True

[linogaliana]

Le check du md5 est du coup pas trop complexe à mettre en oeuvre

[linogaliana]

On pourrait envisager la stratégie suivante:

• Premier download d'une source
• Écriture sur S3 du fichier dézippé (on fait déjà) ET du md5 (ce serait nouveau)
• Check du md5 comme ci-dessus, avant téléchargement:
  • Si le même, on passe à la source suivante
  • Si nouveau: on stocke dans un espace d'archive la source brute qui était sur S3, on réécrit sur S3 la nouvelle source brute et on relance la moulinette cartiflette pour cette source

[tgrandje]

@linogaliana Oui, j'ai commencé à regarder comment intégrer ça. Par contre, il me semble (de mémoire) qu'en l'état actuel, ton téléchargement se fait en local (tempfile) dans une fonction qui n'a pas accès au chemin du s3 -> il faut sans doute réécrire les fonctions avec ça à l'esprit pour éviter un téléchargement si on peut checker le md5 directement (et aussi de manière harmonisée avec un éventuel accès via l'API géoportail et/ou le FTP, qui n'ont pas accès au md5 de la même manière). Je te tiens au courant.

[tgrandje]

@linogaliana Je viens de contrôler ce que j'avais commencé à analyser :

• le plus "simple" me semble de réécrire les fonctions de téléchargement dès le niveau dev.download_store_admin_express (a priori, pas appelée ailleurs dans le code). Parmi les fonctions "filles" appelées ailleurs, j'ai un doute sur "download_write" qui est utilisée aussi dans get_BV. Peux-tu me confirmer qu'on est bien sur une fonction provisoire jamais finalisée à ce stade, et qu'on peut se permettre de "casser" provisoirement la chaîne ?
• je pense qu'avec le roulement des providers, il faut prévoir quelque chose de plus complexe pour stocker les md5 ; à ce stade, on ne peut pas exclure que les md5 soient différents entre un provider et l'autre. Notamment, le md5 du requests.header est un md5 de la requête, pas d'une couche individuelle à l'intérieur de l'archive téléchargée (laquelle contient un fichier md5 détaillé si je me souviens bien). A l'inverse, si on attaque l'API géoportail, le md5 n'est pas disponible avant téléchargement (un sujet à évoquer avec l'IGN ?) et on va donc hasher la couche seule. Du coup, j'imagine plutôt un json centralisé à la racine du s3, peut-être un truc qui référence les deux niveaux de md5 (http response header & couche) et pour chaque provider. Maintenant, comment on pourra détecter quel fichier est le "plus" à jour parmi les différents candidats en provenance des différents providers, je n'en ai aucune idée...

[linogaliana]

@tgrandje , il me semble qu'on est bon maintenant sur cette issue, on peut la fermer ?

[linogaliana]

@tgrandje je ferme, tu ré-ouvres si tu as un état d'âme