-
Notifications
You must be signed in to change notification settings - Fork 661
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
example: add example for S3 ListObjectsV2 with paginator #838
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.
Minor comments
|
||
// NewS3ListObjectsV2Paginator initializes a new S3 ListObjectsV2 Paginator for | ||
// paginating the ListObjectsV2 respones. | ||
func NewS3ListObjectsV2Paginator(client S3ListObjectsV2APIClient, params *s3.ListObjectsV2Input) *S3ListObjectsV2Paginator { |
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 should probably have a page size parameter
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.
Page size is currently a parameter of the s3.ListObjectsV2Input
type. I'm not sure if this should be duplicated here, since it is an optional parameter already present in the input type. I'd think if the user wants to specify this value with a custom size then it should be done on the input value.
What are your thoughts on this?
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.
The reason it's an attribute on the paginator trait is so that clients can expose a consistent interface for providing that value. Between operations and services the member could be any number of things, like Limit
, MaxItems
, PageSize
, etc.
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.
yup though its still an optional parameter in all APIs. By putting it as a parameter on the constructor the SDK is paginator is effectively making it required. The handling for required, but not required parameter, would be to treat the limit parameter as unset if its value is 0. Minor, but this approach still requires the user to pass in a 0
for the default behavior.
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.
Well you can always make a pointer so people pass it in as nil, or have a function to set it as a second step that takes a non-pointer
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.
Adding functional options to add configuration to the paginator might be a good way to do this.
type ListObjectsV2PaginatorOptions struct {
Limit int32 // generic name for all paginators
}
func NewListObjectsV2Paginator(client ListObjectsV2APIClient, params *s3.ListObjectsV2Input,
optFns ...func(*ListObjectsV2PaginatorOptions)
p := s3.NewListObjectsV2Paginator(client, params, func(o *ListObjectsV2PaginatorOptions) {
o.Limit = 10
})
or instead of ListObjectsV2PaginatorOptions
could put Limit
directly on the paginator, but that probably makes it easy to cause unexpected bugs by implying the value can be changed after the paginator is created.
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.
updated to include this pattern 👍
Adds a simple example for Amazon S3 ListObjectsV2 API call with a hand written paginator. Paginator should be updated to use the SDK's generated paginators once available.