1.8 KiB
title
| title |
|---|
| D2 — filtre de fraîcheur sur <code>dateUpdate</code>, de bout en bout |
dateUpdate exposé dans ResourceDTO (champ DTO, pas une colonne — le gel du lot B tient), client manager_api_new édité à la main, colonne ajoutée à la base locale du device (v3 → v4), et le filtre passe de « le fichier est là » à une comparaison de dates. dotnet test 205/205 (2 tests ajoutés), flutter build web ✅, APK dev ✅, tablet-app ✅.
⚠️ La prémisse était fausse, et ça change ce que D2 répare. « Une image remplacée dans le CMS ne remonte jamais » : ce cas n'existe pas — Upload génère un nouvel id à chaque téléversement et le blob vit en pictures/{instanceId}/{resourceId}, donc remplacer une image donne un nouvel id et une nouvelle URL, que l'ancien filtre téléchargeait déjà. ✅ Le vrai cas de péremption est celui que D3 vient de créer : les MP3 déjà sur les devices y sont en .unknown et se déclaraient à jour. Sans D2, D3 ne réparait que les installations neuves.
⚠️ Deux pièges tranchés en écrivant : la montée v4 laisse les dates existantes à NULL et les considère à jour (backfiller à zéro aurait fait re-télécharger toutes les visites de tous les visiteurs sur leur réseau mobile) ; et la boucle en masse héritée de D1 écrasait la date que la boucle de téléchargement venait d'écrire — DatabaseHelper.insert fait un UPDATE de la ligne entière quand l'id existe.