-
Notifications
You must be signed in to change notification settings - Fork 42
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
Consistent pagination experience across all APIs #86
Conversation
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.
I tried to check the 1-based vs 0-based pagination assumption with the following test:
func TestAccQueriesList(t *testing.T) {
ctx := context.Background()
wsc := workspaces.New()
var qs1, qs2 []dbsql.Query
{
result, err := wsc.Queries.ListQueries(ctx, dbsql.ListQueriesRequest{PageSize: 10})
require.NoError(t, err)
qs1 = result.Results
}
{
result, err := wsc.Queries.ListQueriesAll(ctx, dbsql.ListQueriesRequest{})
require.NoError(t, err)
qs2 = result
}
for i := 0; i < len(qs1) && i < len(qs2); i++ {
assert.Equal(t, qs1[i], qs2[i], "Query at index %d not equal", i)
}
}
It fails with an unrelated unmarshalling error:
Error: Received unexpected error:
json: cannot unmarshal object into Go struct field Parameter.results.options.parameters.value of type string
Test: TestAccQueriesList
service/clusters/api.go
Outdated
for _, v := range response.Events { | ||
results = append(results, v) | ||
} | ||
request.Offset += int64(len(response.Events)) // TODO: check for duplicates |
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 todo is very important for all pagination that isn't based on tokens.
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.
Goal: present consistent entity listing for the end-user
TODO:
Databricks REST API has diverse pagination style:
Only 30% of APIs have pagination, though there are two different implementations of it. This PR proposes generating wrapper methods to return consistent type for a collection of all results. It also adds frequently used wrappers, like name-to-id mapping, which could later be used to generate client-level upserts.
Decisions to discuss:
Return type: slice vs iterator
Naming: ListQueriesAll (suffix) vs ListAllQueries (infix) vs all methods returning slices (might be invasive)
Out of scope of this PR