Ne pas émettre d'erreur de mise à jour des métadonnées sur un cache froid (#84933) #11
No reviewers
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/django-mellon#11
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/84933-Traces-concernant-l-impossibilit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
cc1d275e40
to4900475e70
Hop, un premier bout de relecture, comme dit dans mes commentaires il me manque des éléments pour comprendre, je passe à côté d’un truc à la relecture :/
@ -104,4 +109,3 @@
logger.error(
'mellon: metadata path %s : entityID changed %r != %r', path, entity_id, idp['ENTITY_ID']
)
del idp['ENTITY_ID']
Pourquoi laisse-t-on de côté cette suppression dans cette nouvelle version du code ?
Je vais plutôt mettre un raise ici, c'est vraiment pas normal de voir changer l'entity_id.
@ -91,2 +95,2 @@
if last_update == 0 or mtime >= last_update:
idp['METADATA_PATH_LAST_UPDATE'] = time.time()
if mtime > last_mtime or metadata_last_update <= mtime:
Je ne capte pas du tout ce qu’apporte cette deuxième comparaison, pour en avoir une avec
idp['METADATA_PATH_MTIME']
et une autre avecidp['METADATA_LAST_UPDATE']
. Je passe à côté d’un truc, pas compris du tout pas ce que ça apporte :/Je pense qu’il faudrait documenter ces deux
METADATA_*
(parce que je ne comprends pas, par exemple, les cas où la date de dernière modification locale ne correspondrait pas à une modification des métadonnées. J’étais dans l’idée qu’elles ne sont ré-écrites localement que lorsqu’elles ont changé, non ?)C'est une scorie du code intermédiaire, METADATA_PATH_MTIME n'existe même plus en fait (il n'est jamais posé dans idp). Branche à jour.
Ok, je reprends ma relecture.
4900475e70
to2af5808bc0
Voilà, deuxième ronde et encore d’autres interrogations même si je commence à y voir plus clair.
@ -93,0 +86,4 @@
metadata_last_update = idp.get('METADATA_LAST_UPDATE', None)
if not idp.get('METADATA'):
Du détail, mais du code churn ici sur les versions successives et juste ça pourrait devenir
Je trouve plus clair de séparer les conditions sur deux lignes.
@ -158,0 +167,4 @@
metadata_last_update
and 'METADATA' in idp
and (
(now - metadata_last_update) < metadata_cache_time / 2
Pourquoi c’est la moitié de la valeur qui se retrouve utilisée comme durée maximale d’utilisation du cache ?
Je vais virer le / 2.
@ -180,1 +197,3 @@
del idp['ENTITY_ID']
return
if idp.get('METADATA') != response.text:
Ok peut-être un jour (et dans un autre ticket) comparer au sens XML et pas simplement le contenu pour éviter les ré-écritures inutiles (genre des ordres de balises ou d’attributs qui changent, sans aucune conséquence) ?
Ça n'arrive pas.
@ -235,0 +242,4 @@
if 'METADATA_PATH' in idp:
self.load_metadata_path(idp, i)
if 'METADATA_URL' in idp:
Peut-être un 'elif' ici pour éviter de potentiellement charger les métadonnées deux fois, et ceci en choisissant arbitrairement un ordre (genre une chemin prend le dessus sur une URL), avec petit warning sur une double définition des métadonnées par deux moyens différents ?
Ok pour le elif.
@ -239,21 +251,28 @@ class DefaultAdapter:
if entity_id:
idp['ENTITY_ID'] = entity_id
if age and age > (24 * metadata_cache_time):
Y'a un truc louche ici. 10 lignes plus haut on comparaît directement
age
etmetadata_cache_time
, mais ici c’estage
et24 * metadata_cache_time
qu’on compare. Ça a une tête d’erreur d’unité ici.Par défaut METADATA_CACHE_TIME est à 1h, j'ai décidé arbitrairement qu'on lèverait une erreur si le cache a plus de 24h tout simplement.
Ah bon ok j’ai cru qu’on comparait des heures et des jours à un moment.
2af5808bc0
toef3ebcf951
ef3ebcf951
toaf81da4954