Open thbar opened 2 years ago
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
Ah oui top c'est bien utilisé pour ce genre de chose. Super merci !
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à)
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.
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 !
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 |
C'est peut-être un comportement attendu d'une historisation
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
Cette jointure (ou plus propre si tu as 😄) peut être utile pour avoir la dernière resource_history
pour chaque resource
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) deresource_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 chaqueresource
Tu tombes à pic, j'allais l'écrire. Merci !
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).
Ou en filtrant juste sur du GTFS: