Skip to content

feat: add pagination to getAllBuckets #707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

TylerHillery
Copy link
Contributor

@TylerHillery TylerHillery commented Jun 9, 2025

What kind of change does this PR introduce?

Feature to add pagination to the GET buckets endpoint by introducing optional query parameters limit, offset, sortColumn and sortOrder

What is the current behavior?

Currently, we do not allow pagination for GET buckets endpoint.

What is the new behavior?

Now we allow optional query parameters to be passed in to allow pagination.

Additional context

@coveralls
Copy link

coveralls commented Jun 9, 2025

Pull Request Test Coverage Report for Build 15547360956

Details

  • 49 of 49 (100.0%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.04%) to 77.947%

Totals Coverage Status
Change from base Build 15533994820: 0.04%
Covered Lines: 17526
Relevant Lines: 22314

💛 - Coveralls

@TylerHillery TylerHillery marked this pull request as ready for review June 10, 2025 00:13
@TylerHillery TylerHillery requested review from itslenny and fenos and removed request for itslenny June 10, 2025 00:13
@@ -28,9 +28,10 @@ const requestQuerySchema = {
type: 'object',
properties: {
limit: { type: 'integer', minimum: 1, examples: [10] },
offset: { type: 'integer', minimum: 0, examples: [0] },
offset: { type: 'integer', minimum: 1, examples: [1] },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think offset min being 0 is fine. It's "useless" but a lot of time there will be code that sets a counter to 0 and increments it by limit per iteration and we shouldn't error if they pass in 0.

Also, I just checked listObjects and that is the behavior there so that would be consistent.

@@ -288,15 +288,19 @@ export class StorageKnexDB implements Database {
const data = await this.runQuery('ListBuckets', (knex) => {
const query = knex.from<Bucket>('buckets').select(columns.split(','))

if (options?.sortColumn) {
if (options?.search !== undefined) {
query.where('name', 'like', `${options.search}%`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should use ilike and probably %${options.search}% to search anywhere in the string without case sensitivity.

The current dashboard search behavior searches anywhere in the string, but is case sensitive. However, our object search uses ilike so I think we should stay consistent with that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also safely do zz?.search?.length > 0. This will resolve to false if search is undefined or an empty string. The like won't hurt anything if the string is empty, but it also doesn't add anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants