Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
api: paginated results with different ordering #12128
api: paginated results with different ordering #12128
Changes from 2 commits
5942f32
4b7d8d1
ab2a6e1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API musing, feel free to ignore:
I don't love an API where we have to wrap the go-memdb iterator for every struct we want to paginate. But the only alternative that I can see is a new
PageTokenizer
interface implemented byDeployment
,Evaluation
, etc. And thenPaginator
could expect all theResultIterators
return results that arePageTokenizers
. So that's probably not a good path to go down?Or maybe
Paginator
could take aResultIterator
and a function to get the token (it'd close overbyCreateIndex
)? That'd be called something like:But maybe having two function parameters starts calling into question whether
Paginator
should be generic over the type intended to be returned by theResultIterator
. (Oh no, the G-word! 😀 )There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah actually I think generics could clean this up quite a bit. Maybe 1.4 hackathon 🥳
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to the approach we had before, with the
GetID
right? The problem I found is that the struct doesn't know about the request details, so it can't tell if it shouldID
orCreateIndex
unless we add a new field, which sounded not great.This was also something that I experimented with, but it felt like I was writing JavasScript 😅
Another interface I tried was to have a separate method in the
Iterator
, so like:But that didn't help much because you would still need to wrap the
ResultIterator
.Maybe we can do it with two interfaces? If the iterator implements an interface with
GetToken
we would use that, otherwise we useGetID
from the raw element like before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. We'd have to thread the
CreateIndex
through somehow, which ends up being the same as the "pass a function to get the token" implementation.😆
I don't know if you can actually check that without reflection or calling a possibly non-existent method?
In any case, I think what we've got here will get the job done. We can always come back and refine it as we have more paginated API examples. (Ex. if we end up wanting to paginate an API by neither ID nor CreateIndex)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. The two interfaces worked, but it was weird to have two very different ways to integrate with the
Paginator
.