Project

General

Profile

Bug #54442

opendatasoft: trier les résultats

Added by Nicolas Roche 4 months ago. Updated 29 days ago.

Status:
Solution déployée
Priority:
Normal
Assignee:
Target version:
-
Start date:
31 May 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Pour que les résultats soient triés lors de leur présentation sous forme de liste.


Files


Related issues

Related to Passerelle - Bug #55698: opendatasoft: permettre de configurer le paramètre limit dans les requêtesSolution déployée20 Jul 2021

Actions

Associated revisions

Revision 27380a6d (diff)
Added by Nicolas Roche about 1 month ago

opendatasoft: add sort field (#54442)

History

#1

Updated by Nicolas Roche 4 months ago

#3

Updated by Nicolas Roche 4 months ago

  • Subject changed from opendadasoft: trier les résultats to opendatasoft: trier les résultats
#5

Updated by Frédéric Péters 3 months ago

        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.

#6

Updated by Nicolas Roche 3 months ago

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

Rien à voir, mais j'étais passé à côté, sort fait parti des paramètres acceptés par l'API
https://help.opendatasoft.com/apis/ods-search-v1/#dataset-search-api

Sorts results by the specified field. By default, the sort is descending. A minus sign - may be used to perform an ascending sort. Sorting is only available on numeric fields (Integer, Decimal), date fields (Date, DateTime), and on text fields that have the sortable annotation

ex: https://documentation-resources.opendatasoft.com/api/datasets/1.0/search?exclude.publisher=GeoNames&sort=-modified

#7

Updated by Frédéric Péters 3 months ago

(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.

#8

Updated by Frédéric Péters 3 months ago

  • Subject changed from opendatasoft: trier les résultatshttps://documentation-resources.opendatasoft.com/api/datasets/1.0/search?exclude.publisher=GeoNamJe pensais que c'était une bonne chose de trier d'office sur 'text' pour que les listes dans wcs, les champses&sort=-modified to opendatasoft: trier les résultats
#9

Updated by Nicolas Roche 3 months ago

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'.

#11

Updated by Nicolas Roche 3 months ago

Avec le paramètre sort également passé comme paramètre au endpoint search .

#12

Updated by Nicolas Roche 3 months ago

  • Status changed from Solution proposée to En cours

juste autoriser le champs dans l'URL et le propager

Si ça convient, je repars là dessus.

#14

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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

#15

Updated by Nicolas Roche 2 months ago

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.

#16

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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.

#17

Updated by Nicolas Roche 2 months ago

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.

#18

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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.

#19

Updated by Nicolas Roche 2 months ago

  • Related to Bug #55698: opendatasoft: permettre de configurer le paramètre limit dans les requêtes added
#21

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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...

#22

Updated by Nicolas Roche 2 months ago

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.)

#23

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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é.

#24

Updated by Nicolas Roche 2 months ago

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é ?

#25

Updated by Frédéric Péters 2 months ago

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.

#26

Updated by Nicolas Roche 2 months ago

Pile.

0002 : J'en profite pour retirer l'envoie du paramètre "q=" quand il n'est pas renseigné
(ça faisait moche dans les tests et ça fonctionne tout aussi bien).

0003 : Je retire également l'envoie du paramètre "sort=" sur la recherche par identifiant.
Comme on attend un seul enregistrement, à mon avis ça n'a pas non plus de sens de demander un trie.

#27

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

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.

#28

Updated by Nicolas Roche 2 months ago

Merci.

Enfin, pourquoi faire 3 patches ?

Je pensais ainsi faciliter la relecture et augmenter mes chance pour que ce patch soit validé.

C'était aussi dans l'idée de rebasculer un jour sur le tri dans la recherche (la motivation première de ce ticket) :
une liste en autocomplétion sur les nom de rues dans wcs renvoie des choix dans un ordre (celui d'opendatasoft) étrange.
Mais j’abandonne cette idée parce que le trie opendatasoft n'est pas systématique sur les champs texte.

#29

Updated by Thomas Noël (congés → 11 octobre) 2 months ago

  • Status changed from Solution proposée to Solution validée
#30

Updated by Nicolas Roche about 1 month ago

  • Status changed from Solution validée to Résolu (à déployer)
commit 27380a6dd11ae7a0c2a5647e5fe879d477765bda
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Fri Jun 25 19:24:46 2021 +0200

    opendatasoft: add sort field (#54442)
#31

Updated by Frédéric Péters 29 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF