Erreur 500 sur les retour du endpoint dataset

[rkouere]

Lorsque l'on essaie d'accéder à un dataset via le endpoint dataset/ avec une date de mise à jour à false, on a une erreur 500
Ex : [url magma]/dataset/a85dab6c-ef0f-4caa-9763-c7f8c840e216?dateMiseAJour=false

Si on utiliser [url magma]/dataset/a85dab6c-ef0f-4caa-9763-c7f8c840e216?dateMiseAJour=true, on a un retour mais sans date de mise à jour

je ne suis pas sûr à quoi sert le boolean "dateMiseAJour"

[GtanSndil]

@ChristopheYon
1/ Si dateMiseAJour est à false, on est censé renvoyer plusieurs attributs.
Pour les cas que j'ai regardés, l'absence de disseminationStatus et de wasGeneratedBy n'est pas traité et cause une erreur 500.
En corrigeant, on obtient :
{
"id": "a85dab6c-ef0f-4caa-9763-c7f8c840e216",
"uri": "http://bauhaus/catalogues/jeuDeDonnees/a85dab6c-ef0f-4caa-9763-c7f8c840e216",
"catalogRecordCreated": "2024-12-09T12:00:00.000",
"catalogRecordModified": "2024-12-09T12:00:00.000",
"catalogRecordCreator": "DG75-L201",
"catalogRecordContributor": "DG75-L201",
"identifier": "DD_CNA_BRANCHES",
"validationState": "Provisoire, jamais publiée",
"title": [
{
"content": "Activité des branches de l'économie",
"lang": "fr"
},
{
"content": "Activité des branches de l'économie",
"lang": "en"
}
]
}
est-ce que ce retour convient ?
Peut-être qu'il faudrait gérer également le cas des autres champs non renseignés si ces cas existent en base ?

2/ si dateMiseAJour est à true, on a 2 soucis :

• un souci sur la requête qui n'utilise pas dcat:CatalogRecord qui permet de retrouver dcterms:modified.
• un souci sur la base : on a 2 catalogRecord pour le même dataset : http://bauhaus/catalogues/entreecatalogue/... (tout en minuscules) et http://bauhaus/catalogues/entreeCatalogue/... (camelCase) donc même en corrigeant la requête, on se retrouve avec 2 dates. A mon avis il y a donc un souci en base à régler.

[ChristopheYon]

Le retour me semble convenir.
Sinon pour la date de mise à jour, effectivement il faut probablement aller chercher la date dans le CatalogRecord qui est lié au jeu de donnée par le prédicat foat:primaryTopic. Et il semble bien y avoir un doublon sur certains jeux de données. Dans ce cas, il faut prendre le premier qui vient (et qu'on corrige les données).
Cela étant : ce paramètre dateMiseAJour correspond à une demande qui semble obsolète et non pertinente (récupérer seulement la date de mise à jour d'un jeu de données pour faire de l'incrémentiel). Donc je pense qu'on pourrait purement et simplement le supprimer (ie : faire la solution la plus simple entre le supprimer et le faire marcher)