L'attribut "filesize" n'est pas tout le temps renseigné sur les ressources

[thbar]

Je me demande à quoi sert encore cet attribut (il n'est en tout cas pas dans le retour d'API de la page index https://transport.data.gouv.fr/api/datasets à toute première vue), et je n'ai pas été voir, je note juste qu'il est souvent à blanc dans la base, du coup je me demande s'il serait souhaitable de le remplir à minima, ou de le supprimer etc.

Bref son rôle à clarifier, en tout cas pas pratique pour filtrer rapidement des ressources, ce que j'espérais faire (on peut jointurer sur ResourceHistory, quand la donnée est bien capturée).

select filesize IS NULL as f, count(*) from resource group by f

f	count
f	254
t	621

Ou en filtrant juste sur du GTFS:

select filesize IS NULL as f, count(*) from resource where format = 'GTFS' group by f 

f	count
f	157
t	327

[AntoineAugusti]

Il est pas renseigné de manière uniforme mais avait été très utile pour faire https://github.com/etalab/transport-site/pull/2041 par exemple

[thbar]

Ah oui top c'est bien utilisé pour ce genre de chose. Super merci !

[AntoineAugusti]

Déterminer si c'est encore utile/utilisé ou si on peut simplement utiliser les ResourceHistory pour ce besoin ? (me semble que c'est stocké là)

[thbar]

Déterminer si c'est encore utile/utilisé ou si on peut simplement utiliser les ResourceHistory pour ce besoin ? (me semble que c'est stocké là)

J'ai l'impression qu'on peut bien s'en tirer via la ResourceHistory effectivement

select resource_id, filesize, payload ->> 'filesize' from resource_history
INNER JOIN resource ON resource_history.resource_id = resource.id
where filesize is not null
order by resource_history.id desc
limit 10

resource_id	filesize	?column?
80937	52816324	35631512
79668	134023773	135415705
79624	35422140	35799236
81222	212481	211667
79668	134023773	134023773
79624	35422140	35422140
80937	52816324	52815046
80725	2386409	2391592
79668	134023773	135588263
80742	4234126	4233024

En prime c'est renseigné davantage:

with data as (
select resource_id, filesize, payload ->> 'filesize' from resource_history
INNER JOIN resource ON resource_history.resource_id = resource.id
order by resource_history.id desc
)

select count(*) from data where filesize IS NULL

Donne

count
54810

tandis que:

with data as (
select resource_id, filesize, payload ->> 'filesize' as alt_filesize from resource_history 
INNER JOIN resource ON resource_history.resource_id = resource.id
order by resource_history.id desc
)

select count(*) from data where alt_filesize IS NULL

Donne:

count
0

Je propose de garder ouvert mais dans l'optique de supprimer ce champ legacy, à un moment.

[thbar]

Cela dit, voir defp transform_resource(resource) do, ça va générer du N+1 si on ne fait pas attention, à bien gérer donc !

[ptitfred]

Observation lors de ma lecture de l'issue:

Les filesize diffèrent sensiblement pour ~2000 resources:

with rps as (
  select resource.id, resource.filesize, resource_history.payload ->> 'filesize' as payload_filesize, coalesce(resource.filesize, 0) - cast(resource_history.payload ->> 'filesize' as int4) as diff
  from resource
  join resource_history on resource.id = resource_history.resource_id
  where filesize <> cast (payload ->> 'filesize' as int4)
) select * from rps order by abs(rps.diff) desc limit 10;

id	filesize	payload_filesize	diff
38867	305200279	1359	305198920
79668	247584567	43715772	203868795
79668	247584567	48797069	198787498
79668	247584567	48802071	198782496
79668	247584567	48802071	198782496
79668	247584567	48821625	198762942
79668	247584567	48842997	198741570
79668	247584567	48843189	198741378
79668	247584567	48845540	198739027
79668	247584567	48845540	198739027

[ptitfred]

C'est peut-être un comportement attendu d'une historisation

[AntoineAugusti]

resource_history correspond à des snapshots d'une ressource. Quand une ressource est stable (ie son contenu est remplacé par du nouveau contenu/un nouveau fichier) il est me parait normal de constater que des snapshots passés aient une taille de fichier différente que l'état actuel.

Resource#79668 correspond à un export GeoJSON des données IRVE statiques donc varie au quotidien avec plus ou moins de bornes dans le fichier, expliquant une différence de taille du fichier.

resource.filesize est l'état actuel. resource.filesize devrait être proche de la dernière version (la plus récente) de resource_history.payload->>'filesize' en tout cas

[AntoineAugusti]

Cette jointure (ou plus propre si tu as 😄) peut être utile pour avoir la dernière resource_history pour chaque resource

[ptitfred]

resource_history correspond à des snapshots d'une ressource. Quand une ressource est stable (ie son contenu est remplacé par du nouveau contenu/un nouveau fichier) il est me parait normal de constater que des snapshots passés aient une taille de fichier différente que l'état actuel.

Resource#79668 correspond à un export GeoJSON des données IRVE statiques donc varie au quotidien avec plus ou moins de bornes dans le fichier, expliquant une différence de taille du fichier.

resource.filesize est l'état actuel. resource.filesize devrait être proche de la dernière version (la plus récente) de resource_history.payload->>'filesize' en tout cas

Ok c'est ce que j'avais cru comprendre.

Cette jointure (ou plus propre si tu as 😄) peut être utile pour avoir la dernière resource_history pour chaque resource

Tu tombes à pic, j'allais l'écrire. Merci !