-
Notifications
You must be signed in to change notification settings - Fork 22
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
feat(HMS-2248): Add token support for list templates #626
Conversation
f418b03
to
d5175a7
Compare
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 same concern.
Now that I see we have two combinations:
- limit + offset
- limit + token
I think composed type does not make too much sense, checking for nil
or better for 0
and/or empty string is also fine.
Still, I recommend to create the functions that will check for nil
(in case context does not contain any value) and return 0
or ""
in that case so checks are easy.
Launch template test failing. Not able to list the templates. |
65e5373
to
a0b1df6
Compare
I will update this PR once #625 will get merged, there are a lot of conflicts but feel free to test it out. |
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 wonder (and this is really just a thought) if we actually need to do this? Launch templates will usually not be in hundreds and if they do, it does not make sense to paginate in the UI, but search, so I guess we would be fine here not implementing pagination, but only search and some indication of "there is more", but no way of fetching more.
I guess that would quite simplify the whole pagination effort and IMO it would be good enough solution.
I share the sentiment, but I would propose to do at least one pagination for every single type (SQL, sources, AWS, GCP) so we know for sure the design is good. We might not even use it in the UI but we will have backend API tests, documented API and confidence that it works. |
/retest |
My point was, if it would be bit of a struggle to implement (especially if we would want to have same pagination for all endpoints), I'd prefer not to waste the effort, but if we think it's not a big deal, lets do it :) |
a0b1df6
to
ce06412
Compare
api/openapi.gen.json
Outdated
"previous": "" | ||
}, | ||
"metadata": { | ||
"total": 0 |
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.
Not sure why it created the total here if it is empty and I am using the omitempty tag.
Wanted to change the metadata struct to pointer but it is the same discussion as on Slack
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 only have naming conventions suggestions. I still do propose the refactoring (single root JSON field) but if you like to keep it this way I just suggest to get rid if the too generic Info (I suggest Metaroot/Metadata).
@@ -338,34 +339,37 @@ func (c *ec2Client) DescribeInstanceDetails(ctx context.Context, InstanceIds []s | |||
return instanceDetailList, nil | |||
} | |||
|
|||
func (c *ec2Client) ListLaunchTemplates(ctx context.Context) ([]*clients.LaunchTemplate, error) { | |||
func (c *ec2Client) ListLaunchTemplates(ctx context.Context) ([]*clients.LaunchTemplate, *string, error) { |
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.
Why pointer? My first idea is empty string = no token.
} | ||
|
||
return templatesList, nil | ||
return templatesList, &nextToken, nil |
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.
Ditto - the same concern.
internal/page/page.go
Outdated
@@ -33,12 +34,12 @@ type Links struct { | |||
Next string `json:"next"` | |||
} | |||
type Metadata struct { | |||
Total int `json:"total"` | |||
Total int `json:"total,omitempty"` | |||
} | |||
|
|||
type Info struct { |
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.
My suggestion would be renaming this to Metaroot
instead of Info
, that would include NewMetaroot
.
Alternatively, I suggest to rename Metadata to just Data (keeping variable and JSON field as "metadata") and Info to Metadata.
Finally, my third suggestion is simply move links into metadata as this sets a bad practice - it feel like it is okay to pollute the root JSON namespace with fields while a single "metadata" field could be a nice solution with no other fields added.
internal/page/page.go
Outdated
func (o limitOffset) String() string { | ||
return strconv.Itoa(int(o)) | ||
} | ||
|
||
func APIInfoResponse(ctx context.Context, r *http.Request, total int) *Info { | ||
func NewInfo(ctx context.Context, r *http.Request, total int) *Info { |
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.
Maybe NewOffsetInfo
and the other one NewTokenInfo
? (Alternatively NewOffsetMetadata
if you choose to do the refactoring I recommend.)
78ee1aa
to
1921d41
Compare
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 so much cleaner, only documentation typos.
@ezr-ondrej are you happy with this?
cmd/spec/parameters.go
Outdated
|
||
var TokenQueryParam = Parameter{ | ||
Name: "token", | ||
Description: "The token used for requesting the next page of results; empty for the first page", |
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.
Description: "The token used for requesting the next page of results; empty for the first page", | |
Description: "The token used for requesting the next page of results; empty for the last page", |
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 was not what I meant here, I meant that an empty token leads to the first page.
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.
Oh it is a bit unclear but it is fine, thanks.
Tests are failing with There are two options, you can either create "Metaroot" type for the root field, or make use of Go anonymous struct directly in |
It is a problem in the iqe tests in my opinion. @akhil-jha ? |
func (s *LaunchTemplateResponse) Render(_ http.ResponseWriter, _ *http.Request) error { | ||
return nil | ||
Data []*LaunchTemplateResponse `json:"data" yaml:"data"` | ||
Metadata page.Metadata `json:"metadata" yaml:"metadata"` |
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.
Ah here it is, so the root is correct actually. Tests need to be updated I guess.
1921d41
to
6758309
Compare
I think IQE REST client needs to be regenerated, let’s wait what @akhil-jha or @mshriver have to say. |
6758309
to
8b1a4a5
Compare
@adiabramovitch you closed the PR? |
Depends on #625
This PR introduces pagination support for AWS and GCP by returning the received token when fetching the corresponding page. To validate the retrieval of AWS pages, the token needs to be escaped since it is in base64 format.
However, tests are currently missing, andI plan on adding those once will get some feedback. Additionally, tests are failing due to the initial commit missing limit and offset. I plan to stub them and proceed with adding the tests once this implementation is agreed upon.
Please let me know if you have any feedback or suggestions regarding this approach before proceeding with the test implementation.
For easy review just take a look at the changes made by the second commit, once the dependent PR will be merged i'll rebase.