-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publication catalogue sur data.gouv.fr #286
Comments
Proposition d'implem (en mode brouillon -- sera poursuivie/approfondie lundi) Compréhension du besoinAfin de pouvoir rendre public les catalogue sur data.gouv.fr il est nécessaire de rendre disponible un fichier contenant l'ensemble des jeux de données du catalogue. Le format de fichier retenu est le Ce fichier sera disponnible sur une URL dédiée User stories
Details d'implémentationETQ administrateur (DINUM), je veux un fichier de tous les catalogues publics sur data.gouv.fr**Analyse de l'existantLa commande GetAllDatasets() retourne un ensemble de
Cette commande utilise la méthode Implem
Questions :
=> a mon avis il est aussi possible d'utiliser la même query en rajoutant une On aurait qqch comme ceci
Le truc c'est que je vois pas bien comment ça s'utiliserait. J'imagine que ça doit être autour de cet endroit A ce stade là, on devrait être en capacité de récupérer tous les Datasets "publics"
L'idée serait d'exposer ce fichier CSV via une route sur le serveur un peu à la manière d'un endpoint d'API Idée de nom de route Questions :
=> si on les génère à l'avance ça implique de stocker un fichier quelque part (sur le serveur? Sur un S3 ?) A chaque création/modification de jeu de donnée il faudra penser a aussi mettre à jour/créer le fichier ... @Florimond un avis ? Tâches
ETQ administrateur (DINUM), je veux un fichier de tous les catalogues publics sur data.gouv.frTo Do |
Pour l'endpoint, j'aurais vu qqc comme:
En effet :
De mon point de vue, puisqu'on est sur un cas d'utilisation de l'API différent, il vaut mieux créer une "chaîne" (route, query) différente. En revanche pour les repositories il faut réutiliser ce qui existe il me semble, oui, car ils sont sensés être l'interface "générique" avec le modèle de données. En particulier, j'imagine que le résultat de la nouvelle query sera un objet particulier (par ex
C'est un objet qui permet de filtrer les résultats. Les query params de la recherche avancée finissent dedans. :) En l'occurrence
Une 3e option : générer le CSV à la demande avec mise en cache (par ex 1 jour). En effet les catalogues sont vivants et le site n'est pas statique. On ne peut pas les "générer à l'avance" : il faut pouvoir récupérer une version à jour. Mais un endpoint qui ferait effectivement le calcul à chaque fois est très peu efficace. Tout dépend du rythme de mise à jour côté publication DataGouv. Donner la possibilité d'une mise à jour quotidienne semble acceptable. Concrètement le cache devrait être côté API, donc dans une première approche utiliser un stockage en mémoire sur les serveurs. Pour le calcul de l'expiration : soit 1 jour après le dernier calcul, soit chaque jour à une heure fixée (par ex 1h du matin). Dans l'idéal, pour bien comprendre ce qu'on fait, on ferait une implémentation custom avant de se demander si on pourrait s'appuyer sur une lib existante (cashews, async-cache, etc).
À ce jour on n'a pas encore de notion de restriction d'accès : #289. Donc tout jeu de donné catalogué est "public". Ça me semble une "contrainte" acceptable dans un premier temps ? cc @johanricher. De toute façon la publication sur DataGouv est à l'initiative d'un humain, l'endpoint existera mais ne branchera pas tout seul à un jeu de données dans DataGouv. |
Oui le critère d'acceptation de ce ticket c'est "un CSV par catalogue", et qu'il soit téléchargeable sans auth. La US ("je veux un fichier de tous les catalogues") sert juste à éclairer le besoin de façon plus globale. D'ailleurs ce besoin d'avoir cet espèce de "meta catalogue" interministériel pourrait être adressé par quelqu'un d'autre que nous en faisant une agrégation des différents catalogues CSV. |
Re-oui cf. ce que j'ai mis en "critères d'acceptation" et "aller plus loin" |
Re-re-oui. Le critère d'acceptation minimal c'est un CSV qui reflète le catalogue et son schéma, tel que ça a été implémenté dans le code du logiciel et en base. Ce vers quoi il faut tendre, c'est à dire ce qui est le plus fonctionnel et utile pour l'utilisateur, c'est que le CSV soit conforme au schéma Table Schema du catalogue mais ça engendre de la complexité notamment les points que tu mentionnes, donc à faire dans un second temps (par contre svp listez ça dans un ticket, sinon dans un pad, et je ferai un ticket). |
Concernant ce qui est acceptable comme rythme de mise à jour du fichier servi par l'API. L'idée du cache me paraît la meilleure car si je comprends bien on implémente quand même la génération à la demande et avec le cache on pourra trouver un compromis entre la "fraicheur" du fichier et la charge du calcul. Dans un premier temps une mise à jour du fichier toutes les 24h me semble acceptable. Je pense que dans un second temps il faudra descendre en dessous de l'heure comme fréquence de mise à jour mais ça pourra faire l'objet d'un ticket dédié. |
d'acc merci pour les retours. Je vais approfondir mon analyse lundi |
@florimondmanca Hors sujet, mais je vois qu'on me tag une nouvelle fois en parlant de toi. Il faut vraiment que tu changes de prénom. C'est moi le seul et l'unique! ;P |
Ce message est juste génial! La probabilité du truc! |
(Analyse en version quasi finale) Compréhension du besoinAfin de pouvoir rendre public les catalogue sur data.gouv.fr il est nécessaire de rendre disponible un fichier contenant l'ensemble des jeux de données du catalogue. Le format de fichier retenu est le Ce fichier sera disponnible sur une URL dédiée User stories
Details d'implémentationETQ administrateur (DINUM), je veux un fichier de tous les catalogues publics sur data.gouv.frAnalyse de l'existantLa commande GetAllDatasets() retourne un ensemble de
Cette commande utilise la méthode ImplemRécupération des Datasets "publiabes"Handler et query Le mieux serait de créer une query (idée de nom : Ce handler retournerait une view
(barrer car pas nécessaire dans un premier temps) Le truc c'est que je vois pas bien comment ça s'utilisera Réutiliser le repository avec le filtre "organization" Il va être aussi nécessaire de modifier le repository Transformation de la
|
Ça me semblerait curieux étant donné qu'on exporte "un catalogue" et non pas "un jeu de données". On n'a pas à ce jour de "page de catalogue" il me semble. Aussi je ne sais pas où pourrait apparaître ce "bouton / lien export catalogue"... |
T'as raison @florimondmanca j'ai écrit trop vite sans faire la dinstinction catalogue/jeu de donnée Dans la UI le seul endroit où l'on a une représentation graphique du catalogue c'est la liste qui est en home page quand on est connecté. Est-ce que l'on rajouterais un bouton à chaque ligne ? |
Une intervention sur le front telle que l'ajout d'un bouton n'est pas un critère d'acceptation de ce ticket (c'est à dire pas nécessaire pour répondre au besoin exprimé). C'est plutôt une "idée pour la suite" (cf. "Aller plus loin"), bien distincte de ce ticket, et qu'il faudrait le cas échéant d'abord exprimer sous forme de besoin utilisateur, puis designer et enfin prioriser dans une itération ultérieure. |
Pour être clair sur comment ça va se passer en pratique, avec cette feature telle que spécifiée et à implémenter ici : Un lien pour télécharger un catalogue sera sous la forme D'autres utilisateurs plus avancés pourront découvrir (ou être orientés vers) cette feature grâce à la doc de notre API où ce endpoint sera spécifié (encore une fois je vous laisse me corriger si je dis une bêtise). |
j'ai tout de même une question p-e lié a un manque de compréhension Si on part du principe qu'il suffit de mettre une URL C'est bien cela ? |
A ce stade, notamment avant que #289 soit implémenté, oui c'est bien ça. |
@johanricher On a mergé #480, l'endpoint CSV public. Je vais déployer. Il semble que malgré les suites possibles évoquées (niveau d'accès...), on puisse fermer cette epic "contractuelle" ? |
C'est en prod sur https://catalogue.data.gouv.fr/api ? Est-ce que ce endpoint peut être documenté ("Get catalog CSV") sur https://catalogue.data.gouv.fr/api/docs ? |
Mon message était un peu avance, je viens de déployer, tu peux réessayer d'y accéder. https://catalogue.data.gouv.fr/api/docs#/catalogs/export_catalog_catalogs__siret__export_csv_get |
Magnifique |
Issues liées
Idées pour la suite (hors périmètre de ce ticket) :
The text was updated successfully, but these errors were encountered: