Projet

Général

Profil

Bug #55698

opendatasoft: permettre de configurer le paramètre limit dans les requêtes

Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans. Mis à jour il y a plus de 2 ans.

Statut:
Fermé
Priorité:
Normal
Version cible:
-
Début:
20 juillet 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Parce qu'on ne va pas s'amuser à rajouter des ?limit= abscons dans les appels aux requêtes.


Fichiers


Demandes liées

Lié à Passerelle - Bug #54442: opendatasoft: trier les résultatsFermé31 mai 2021

Actions

Révisions associées

Révision 3d569fa1 (diff)
Ajouté par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans

opendatasoft: add limit parameter to queries (#55698)

Historique

#1

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans

  • Lié à Bug #54442: opendatasoft: trier les résultats ajouté
#4

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans

#5

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à Solution validée

Je ne comprends pas bien la nécessité du changement d'ordre de limit dans les signatures mais soit. Aussi on perd la possibilité de mettre un limit explicite dans q, ça non lus je ne sais pas pourquoi.

#6

Mis à jour par Thomas Noël il y a plus de 2 ans

(De toute façon AFAIK ce patch va être sérieusement rebasé avec l'apparition de sort entre temps -- si tu veux le resoumettre avant, Nicolas, tu peux)

#7

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans

Je ne comprends pas bien la nécessité du changement d'ordre de limit dans les signatures mais soit.

C'est pour rendre le code plus cohérent, je regroupe les attributs du connecteur en premier, puis en second les paramètres de la requête.

Aussi on perd la possibilité de mettre un limit explicite dans q, ça non lus je ne sais pas pourquoi.

Je me suis mis à niveau sur #54442, mais oui je devrais peut-être laisser cette possibilité et l'ajouter également pour l'attribut sort.
Mais alors il se posera la question de savoir s'il faut privilégier l'attribut ou le paramètre de la requête si les deux sont renseignés ?

#8

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Nicolas Roche a écrit :

Je ne comprends pas bien la nécessité du changement d'ordre de limit dans les signatures mais soit.

C'est pour rendre le code plus cohérent, je regroupe les attributs du connecteur en premier, puis en second les paramètres de la requête.

Ah ouais je vois, y a que moi qui me prend des remarques de code churn inutile. Ça me semble particulièrement inutile ici :)

Aussi on perd la possibilité de mettre un limit explicite dans q, ça non lus je ne sais pas pourquoi.

Je me suis mis à niveau sur #54442, mais oui je devrais peut-être laisser cette possibilité et l'ajouter également pour l'attribut sort.
Mais alors il se posera la question de savoir s'il faut privilégier l'attribut ou le paramètre de la requête si les deux sont renseignés ?

En général on privilégie le paramètre de la requête, après on peut mettre un maximum légitime si on y voit un DOS possible, je ne sais pas à quoi sert ce connecteur, mais en général on met une valeur par défaut et un max; si ça sert principalement à des champs autocomplétion on est toujours sur 10 comme limite il me semble coté w.c.s.

#9

Mis à jour par Thomas Noël il y a plus de 2 ans

  • Statut changé de Solution proposée à Solution validée

Benjamin Dauvergne a écrit :

Ah ouais je vois, y a que moi qui me prend des remarques de code churn inutile.

:-)

Aussi on perd la possibilité de mettre un limit explicite dans q, ça non lus je ne sais pas pourquoi.

Je me suis mis à niveau sur #54442, mais oui je devrais peut-être laisser cette possibilité et l'ajouter également pour l'attribut sort.
Mais alors il se posera la question de savoir s'il faut privilégier l'attribut ou le paramètre de la requête si les deux sont renseignés ?

En général on privilégie le paramètre de la requête, après on peut mettre un maximum légitime si on y voit un DOS possible, je ne sais pas à quoi sert ce connecteur, mais en général on met une valeur par défaut et un max; si ça sert principalement à des champs autocomplétion on est toujours sur 10 comme limite il me semble coté w.c.s.

Oui, si on voulait autoriser les deux on privilégierait le paramètre venant de request. Mais je me permets de valider le patch ainsi, il est bien.

Pour faire que limit et sort soient surchargeables lors de l'usage des requêtes, on peut faire un autre ticket... mais je doute que ça soit utile en vrai.

#10

Mis à jour par Nicolas Roche (absent jusqu'au 3 avril) il y a plus de 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 3d569fa1d10b302447a13ca078d58c2af82e7a10
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Tue Jul 20 12:25:31 2021 +0200

    opendatasoft: add limit parameter to queries (#55698)
#11

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF