action #121048: Add pagination for GET /api/v1/bugs - openQA Project (public) - openSUSE Project Management Tool

Actions

action #121048

closed

coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes

coordination #92854: [epic] limit overload of openQA webUI by heavy requests

action #97190: Limit size of initial requests everywhere, e.g. /, /tests, etc., over webUI and API

action #119428: Ensure users can get all the data for limited queries, e.g. with pagination

Add pagination for GET /api/v1/bugs

Added by kraih about 2 years ago. Updated about 2 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

kraih

Category:

Feature requests

Target version:

Ready

Start date:

2022-11-22

Due date:

% Done:

Estimated time:

Description

Motivation¶

Proper pagination is planned for every query and API route in #119428. After #120841 has been implemented we now have a prototype to replicate. So this needs to be done for GET /api/v1/bugs.

Acceptance criteria¶

AC1: API endpoint GET /api/v1/bugs has pagination

Suggestions¶

Use limit/offset query parameters and prev/next/first relations in Link headers
If possible use the DBIx::Class features for limit and offset

Related issues 2 (1 open — 1 closed)

Actions

Copy link

Updated by kraih about 2 years ago

Copied from action #120841: Add pagination for GET /api/v1/assets size:M added

Actions

Copy link

Updated by kraih about 2 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by okurz about 2 years ago

@kraih I think the existing issues in our backlog are at least equally important so I suggest to not add this ticket to the backlog immediately. And in particular for feature requests I suggest to properly estimate first before starting the work.

Actions

Copy link

Updated by kraih about 2 years ago

okurz wrote:

@kraih I think the existing issues in our backlog are at least equally important so I suggest to not add this ticket to the backlog immediately. And in particular for feature requests I suggest to properly estimate first before starting the work.

I hope you realise that this will make me not split up larger tickets in the future. I'm trying hard here to use the ticket system properly and reduce subtasks to something easily estimatable, despite hating Redmine with a passion. If that means extra long turnaround times because subtasks have to reach the ready queue again, there is no incentive to do it. Anyway... the PR was already half finished when i saw your comment, and is kinda important since it moves the Link header code from #120841 into a shared helper. https://github.com/os-autoinst/openQA/pull/4934

Actions

Copy link