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