Produits Entr'ouvert » Passerelle

1. Je n'ai pas mis de validateur sur le nouveau champ car je n'ai pas trouvé quelle syntaxe pouvait faire planter urlparse.parse_qs(filter_expression, strict_parsing=True).

2. En lui ajoutant un champs texte dédié, l'objet Query fonctionne bien : je passe son contenu en paramètre à search qui l'utilise lors du GET.

Mais si j'appelle directement search, alors je ne sais pas comment traiter ce "morceau d'url qui contient des '&'" reçu via un paramètre de l'URL.

un paramètre "valeur du filtre" et dedans on écrirait "refine.libelle_region=Nouvelle-Aquitaine" et voilà.

En fait ce n'est pas si simple parce qu'il s'agirait d'un paramètre pouvant contenir plusieurs filtres.
Voici un exemple d'expression qu'il me faut prévoir de passer à search comme paramètre de l'URL par l'usager, en utilisant un pré-supposé paramètre "filter_expression" dédié dans le endpoint search :

filter_expression=refine.facetA=valueA&refine.facetB=valueB'

Pour contourner le problème des '&' (faute de mieux) ce patch utilise le kwargs pour passer les filtres.

filter_expression=refine.facetA=valueA & refine.facetB=valueB

Le & fait que je n'arrive pas à passer ce paramètre au endpoint search via l'API HTTP (appelé directement via un appel WS, sans passer par l'objet Query).
Je n'ai pas trouvé de code ailleurs où l'on passerait un tel paramètre "composé".
Ici pour avoir un truc propre, je dirais qu'il faudrait ajouter un champ par filtre,
mais je préfère poser la question parce-que là non-plus ce n'est pas fait comme ça ailleurs.

Dans l'immédiat, je propose de passer les paramètres décomposés dans le kwargs au endpoint search,
parce que c'est ce qui me semble le plus simple :

        filters = urlparse.parse_qs(self.filter_expression)
        kwargs.update(filters)

(merci pour la remarque sur l'import que j'ai oublié de retirer)

Tant mieux si ça ne choque pas.
J'ai pas été bien clair (mais tu m’as compris) et je précise pour d'autres qui passeraient par là,
que l'appel au endpoint search (avec des filtres) aurait cette tête :

$ curl 'https://passerelle.dev.publik.love/opendatasoft/test/search?dataset=world-heritage-unesco-list&refine.continent_fr=Europe+et+Amérique+du+nord&refine.country_fr=France&exclude.category=Cultural'

Et qu'il n'y pas moyen d'indiquer nativement dans l'IHM que l'on peut ajouter des paramètres "[refine|exclude].{facette}={value}" (je n'ai rien prévu dans ce patch pour l'indiquer).

l'endpoint "q" devrait appeler une méthode qui n'est pas l'endpoint

Ok, mais ça ne résoudra pas mon problème, j'en déduis donc que je me suis encore mal exprimé.

Lorsque j’appelle un endpoint, je n'arrive pas à passer en l'état un paramètre qui contient un '&' afin que ce paramètre soit ensuite utilisé pour passer plusieurs paramètres GET à la requête vers le serveur opendatasoft.
Pour l'objet Query, cela fonctionne parce que j'utilise le paramètre stocké en base dans le champ texte, mais si je voulais passer ce champs en paramètre au endpoint q, alors la ligne curl serait du même type que ci-dessus (là ce n'est même pas prévu).

J'ai l'impression qu'il n'y a pas de solution élégante pour gérer ce champs composé, et que le plus conventionnel serait de convenir d'un séparateur autre que '&' pour passer les filtres dans un unique paramètre.

Lorsque j’appelle un endpoint

Je dis qu'il n'y a pas d'endpoint à appeler. Ce qui est ajouté ici est présent dans la définition des requêtes, end of story, jamais reçu jamais recevable dans l'URL.

(compris, merci)

J'ai explicité l'appel pour supprimer le kwargs.

Oui d'accord avec tout (j'ai raté un truc et c'est ce qui a soulevé les 2 interrogations ci-dessus).

Soit je retire le kwargs des paramètres de call_search (pour qu'à ce niveau on décide d'arrêter le n'importe quoi et passer uniquement les paramètres triés sur le volet),
soit je le laise pour que la méthode "q" appele call_search avec le **kwargs et donc potentiellement n'importe quoi.

J'étais parti sur la première version (mais j'avais oublié de retirer le kwargs des paramètres de call_search). A te lire je suppose que tu préfères la seconde version qui génère un plus petit patch.
Mes excuses ici pour le mauvais patch ci-dessus qui a tout embrouillé.

Rien à voir, mais je note ici qu'il me faudra ensuite mettre à jour la page de wiki :

Puis à créer une requête pour renseigner les autres paramètres :
...
* filtre : les filtres 'refine' et 'exclude' à appliquer (https://help.opendatasoft.com/apis/ods-search-v1/#dataset-search-api)
  concaténés avec des '&'.
  ex: refine.continent_fr=Europe et Amérique du nord&exclude.category=Cultural&refine.country_fr=France

A te lire je suppose que tu préfères la seconde version qui génère un plus petit patch.

(c'est ce que j'ai pensé en lisant : "m'interloque totalement, pourquoi n'a-t-il pas pu être laissé comme il était ?")

Dans ce patch tu introduis call_search qui est une nouvelle méthode qui n'a aucune raison d'avoir **kwargs.

oui j'ai complètement bugé, désolé.

Et donc patch avec Query/q qui ne passer plus n'importe quoi qui est arrivé par l'URL, via l'endpoint "q".

J'étais presque à valider et dire que les développements supplémentaires imaginés, comme permettre un gabarit dans filter_expression, pour par exemple y avoir {{now|date:"Y"}} pour filtrer sur l'année actuelle, ce serait pour d'autres tickets.

Mais quand même je pense que c'est peu lisible de taper refine.source=Ville et Eurométropole de Strasbourg&exclude.numero=42&exclude.numero=43. et qu'on pourrait accepter les retours à la ligne, pour comme ça avoir une expression par ligne, et pouvoir écrire :

refine.source=Ville et Eurométropole de Strasbourg
exclude.numero=42
exclude.numero=43

Il s'agirait de modifier help_text pour dire qu'une expression par ligne (plutôt que séparées par des &) et quand il est ppassé filter_expression=self.filter_expression, plutôt faire un '&'.join(self.filter_expression.spitlines()).

une expression par ligne

oui, en effet.

(j'ai oublié de mettre à jour la migration)

commit cac06da89ee1a059bedd1b1ff2a50af0970256ac
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Fri Apr 9 11:39:17 2021 +0200

    opendatasoft: add facet filters (#50212)

commit ecd314d714ba20fb2fc0adb5202b78971f759605
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Mon Apr 12 17:55:39 2021 +0200

    opendatasoft: use APIError into endpoint (#50212)

commit 9b88f614aa8a6aa30afbb4e389f480c44532b999
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Mon Apr 12 17:54:29 2021 +0200

    opendatasoft: correct tests (#50212)