Produits Entr'ouvert » Passerelle

        result.sort(key=itemgetter('text'))

Perso davantage habitué à key=lambda x: x.get('text') qui ne demande pas à chercher d'où vient ce que fait itemgetter.

_~~

Mais sur le fond ça ne pense pas nécessairement approprié d'imposer ce tri, parce que j'imagine que par défaut le tri fourni par opendatasoft peut ou doit avoir un sens.

(c'était pour que les listes affichées dans wcs, les champs soient triés).

Ce qui n'a pas systématiquement du sens.

Je serais pour ajouter à la définition d'une requête un champ permettant de taper l'attribut sur lequel faire le tri (juste un champ texte, pas chercher à produire une liste), que cela soit passé lors de l'appel à opendatasoft, et qu'en l'absence, il ne soit rien fait concernant le tri.

ajouter à la définition d'une requête un champ permettant de taper l'attribut sur lequel faire le tri

Fait,
mais tout bien réfléchi, je me dis que l'on pourrait juste autoriser le camps dans l'URL et le propager,
sans le stocker dans la définition des requêtes,
comme c'est fait par exemple pour le paramètre 'limit'.

Un peu perdu : on ne peut plus passer le sort dans une requête pré-configurée ?

Non, pas plus que pour le paramètre "limit" où l'on fait juste passe-plat.
Dis-moi si tu préfères https://dev.entrouvert.org/issues/54442#note-11 et à ce moment là j'intégrerais également le paramètre "limit" dans le paramétrage de la requête.

Je lisais juste la note #7 :

Je serais pour ajouter à la définition d'une requête un champ permettant de taper l'attribut sur lequel faire le tri (juste un champ texte, pas chercher à produire une liste), que cela soit passé lors de l'appel à opendatasoft, et qu'en l'absence, il ne soit rien fait concernant le tri.

et je vois que ce n'est pas ce qui est proposé dans ton patch.

Oui, j'ai proposé le patch allant dans ce sens https://dev.entrouvert.org/issues/54442#note-11
puis me suis ravisé https://dev.entrouvert.org/issues/54442#note-12.
Comme il n'y a pas eu de réponse depuis, je propose https://dev.entrouvert.org/issues/54442#note-13.

Ce sont des choses que tu as décidé tout seul... sans dire pourquoi tu as changé d'avis. Pour ma part, je reste sur la demande de Frédéric, plus cohérente. On va pas s'amuser à rajouter des ?order= abscons dans les appels aux requêtes.

Je n'ai pas testé, mais habituellement quand on interroge une API de type "search", elle renvoie les résultats dans l'ordre de pertinence. Ca serait dommage de perdre ça, et même gênant dans le cas de l'utilisation de l'autocomplétion. Peux-tu vérifier si les résultats remontent par ordre de pertinence avec de l'opendatasoft qu'on a a disposition ?

Si lors d'une recherche les résultats sont bien renvoyés par ordre de pertinence, alors ça voudra dire qu'il ne faut pas appliquer le "sort" sur les recherches, mais uniquement lors de la remonté de la liste exhaustive (q is None).

Du moins c'est mon avis...

Oui, je le répète (et je vois que c'était pas super clair), ici on fait juste passe plat, il n'y a aucun traitement dans le connecteur concernant le trie.
(Au début j'ai effectivement proposé un patch pour appliquer le trie sur le gabarit de text, puis Fred m'a indiqué comme toi que c'est à opendatasoft de procéder au trie en amont.)

Nicolas Roche a écrit :

Oui, je le répète (et je vois que c'était pas super clair), ici on fait juste passe plat, il n'y a aucun traitement dans le connecteur concernant le trie.
(Au début j'ai effectivement proposé un patch pour appliquer le trie sur le gabarit de text, puis Fred m'a indiqué comme toi que c'est à opendatasoft de procéder au trie en amont.)

Oui, mais quand on envoie un q=xxx et un sort=yyy à l'API search d'opendatasoft, il se passe quoi ? C'est ça que j'aimerai que tu vérifies : que le sort=yyy envoyé ne modifie par l'ordre d'une recherche, pour laquelle on s'attend à recevoir les résultats dans l'ordre de pertinence. Si c'est bien le cas alors ton patch est ok, sinon il faudra retirer le sort= quand un q= est envoyé.

Alors voyons si je te suis et prenons l'exemple des merveilles du monde :
https://examples.opendatasoft.com/api/records/1.0/search/?dataset=world-heritage-unesco-list&q=merveille

Le Mont-Saint-Michel et sa baie sont plus pertinents que les pyramides de Guizeh en tant que "merveille".

$ curl 'https://examples.opendatasoft.com/api/records/1.0/search/?dataset=world-heritage-unesco-list&q=merveille' | json_pp | grep name_fr
(2° position) "name_fr" : "Mont-Saint-Michel et sa baie",
(3)           "name_fr" : "Memphis et sa nécropole –  les zones des  pyramides de Guizeh à Dahchour",

(jusqu'ici je suis d'accord)

Si je trie sur la date d'inscription au patrimoine mondial, vu qu'ils y ont été inscrits la même année, alors j'aimerai retrouver cette même préférence régionale.

$ curl 'https://examples.opendatasoft.com/api/records/1.0/search/?dataset=world-heritage-unesco-list&q=merveille&sort=date_inscribed' | json_pp | grep name_fr
(8)         "name_fr" : "Memphis et sa nécropole –  les zones des  pyramides de Guizeh à Dahchour",
(9)         "name_fr" : "Mont-Saint-Michel et sa baie",

Mince, je tri à l'envers pour voir...

$ curl 'https://examples.opendatasoft.com/api/records/1.0/search/?dataset=world-heritage-unesco-list&q=merveille&sort=-date_inscribed' | json_pp | grep name_fr
(1)         "name_fr" : "Memphis et sa nécropole –  les zones des  pyramides de Guizeh à Dahchour",
(2)         "name_fr" : "Mont-Saint-Michel et sa baie",

Re-mince, visiblement le sort=yyy envoyé modifie l'ordre d'une recherche, pour laquelle on s'attend à recevoir les résultats dans l'ordre de pertinence.
Reste que j'ai peut-être compris de travers la notion d'ordre de pertinence.

quand on envoie un q=xxx et un sort=yyy

Si je l'applique au contexte où les deux paramètres q= et sort= sont renseignés alors ça semble tenir.

$ curl 'https://examples.opendatasoft.com/api/records/1.0/search/?dataset=world-heritage-unesco-list&q=mer&sort=-date_inscribed' | json_pp | grep name_fr
(2)         "name_fr" : "Memphis et sa nécropole –  les zones des  pyramides de Guizeh à Dahchour",
(5)         "name_fr" : "Mont-Saint-Michel et sa baie",

Est-ce que je creuse ce second point, ou le premier point répond à ta question et je retire le sort= quand un q= est envoyé ?

Tu te prends beaucoup trop la tête à inventer des situations et à faire intervenir des données qui ne sont pas visibles, etc. c'est impossible à suivre.

Je ne sais pas ce qui amène ce ticket, les seuls tickets liés sont postérieurs.

Est-ce que je creuse ce second point

Je dirais que non non non faut surtout arrêter de creuser.

Tu prends une pièce de monnaie tu la lances et si c'est pile tu retires sort= quand q= est envoyé, face tu laisses.

0003: le « if sort and not (q or id): » peut agréablement devenir un « elif sort is not None: » posé après le « if id is not None: ... elif q is not None: ... » (c-à-d qu'on ne gère sort qu'en l'absence de id et q)

Au passage, mettre sort=None dans la signature, comme pour id et q.

Aussi, les «update» pour modifier une seule clé d'un dictionnaire, c'est très moche. Je trouverais plus joli de faire « params['sort'] = sort »

Enfin, pourquoi faire 3 patches ? Un seul ça serait sans doute plus facile à lire/comprendre, je pense.