Skip to content
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

Remove classic pagination #5205

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AntonKhorev
Copy link
Collaborator

@AntonKhorev AntonKhorev commented Sep 12, 2024

This removes classic pagination library that's only used for changeset elements pagination:

  • necessary parts of its Paginator class moved to controller's ElementsPaginator
  • necessary parts of PaginationHelper module moved to sidebar_classic_pagination helper

@tomhughes
Copy link
Member

Shouldn't we just be converting changesets to use the same pagination logic as everything else, rather than copying parts of classic pagination into the controller just so we can pretend we got rid of it?

@AntonKhorev
Copy link
Collaborator Author

AntonKhorev commented Sep 18, 2024

Shouldn't we just be converting changesets to use the same pagination logic as everything else

That depends on how significant are the differences between changeset elements and everything else. The differences are:

  • Changesets have an upper bound on the number of elements. There can be a really large and growing number of traces etc. If you wanted to use numbered pages and go to page N, that N could be huge and you'll have to skip a huge number of record with offset. But for changeset elements N can't get higher than 10000 / page size.
  • Changesets don't change once closed. For a list of traces it doesn't make mach sense to be on page 1, 2, 5 etc because new traces are added and old ones are pushed off the page. Changeset elements are not going to be pushed of their page.
  • Traces etc have a well-defined order represented by a single id, changeset elements don't.

@gravitystorm
Copy link
Collaborator

Shouldn't we just be converting changesets to use the same pagination logic as everything else, rather than copying parts of classic pagination into the controller just so we can pretend we got rid of it?

I agree.

  • Changesets have an upper bound on the number of elements. There can be a really large and growing number of traces etc. If you wanted to use numbered pages and go to page N, that N could be huge and you'll have to skip a huge number of record with offset. But for changeset elements N can't get higher than 10000 / page size.

  • Changesets don't change once closed. For a list of traces it doesn't make mach sense to be on page 1, 2, 5 etc because new traces are added and old ones are pushed off the page. Changeset elements are not going to be pushed of their page.

These are good reasons why the paginator doesn't have to be cursor-based, but they aren't reasons why it can't be cursor-based. So I think the simplification of only having one type of pagination is worthwhile.

  • Traces etc have a well-defined order represented by a single id, changeset elements don't.

Since we need a well-defined order for either approach to work, I think it's best to get the order defined and working with the cursor-based pagination.

@AntonKhorev
Copy link
Collaborator Author

These are good reasons why the paginator doesn't have to be cursor-based, but they aren't reasons why it can't be cursor-based. So I think the simplification of only having one type of pagination is worthwhile.

Do you propose to remove the ability to go to page N?

@gravitystorm
Copy link
Collaborator

Do you propose to remove the ability to go to page N?

Sure, I don't see a strong need for that. Particularly if the order hasn't been defined before.

@AntonKhorev
Copy link
Collaborator Author

Do you also propose to remove the ability to see how many elements of each type were changed?

@gravitystorm
Copy link
Collaborator

No.

@AntonKhorev
Copy link
Collaborator Author

These are good reasons why the paginator doesn't have to be cursor-based, but they aren't reasons why it can't be cursor-based. So I think the simplification of only having one type of pagination is worthwhile.

Those were reasons for why this place is different, why it might be feasible not to downgrade the pagination here and why there won't necessarily be any simplification even if we downgrade it.

Since we need a well-defined order for either approach to work, I think it's best to get the order defined and working with the cursor-based pagination.

Do you want to introduce a single id or or some other field (like relation elements have) and sort by it?

Copy link

1 Warning
⚠️ Number of updated lines of code is too large to be in one PR. Perhaps it should be separated into two or more?

Generated by 🚫 Danger

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

Successfully merging this pull request may close these issues.

3 participants