Project

General

Profile

Bug #55698

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

Added by Nicolas Roche 11 days ago. Updated about 21 hours ago.

Status:
Solution validée
Priority:
Normal
Assignee:
Target version:
-
Start date:
20 Jul 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

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


Files


Related issues

Related to Passerelle - Bug #54442: opendatasoft: trier les résultatsSolution validée31 May 2021

Actions

History

#1

Updated by Nicolas Roche 11 days ago

  • Related to Bug #54442: opendatasoft: trier les résultats added
#4

Updated by Nicolas Roche 11 days ago

#5

Updated by Benjamin Dauvergne 1 day ago

  • Status changed from Solution proposée to 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

Updated by Thomas Noël 1 day ago

(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

Updated by Nicolas Roche about 22 hours ago

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

Updated by Benjamin Dauvergne about 22 hours ago

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

Updated by Thomas Noël about 21 hours ago

  • Status changed from Solution proposée to 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.

Also available in: Atom PDF