-
Notifications
You must be signed in to change notification settings - Fork 132
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
Add samples for all AppConfig pager methods (GetSnapshots, GetConfigurationSettings, GetRevisions) with comparisons of what we'd expect the user experience to be. #6341
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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.
It is beyond AppConfig, and this is not question only to you, but maybe we should have a design discussion with the architects, but I am wondering if we should make pageable items as non-nullable, at least, by default - I don't nullable here is the best user experience, and I don't expect nullable vs size == 0 to ever have meaningful distinction in the context of Azure SDK. Ideally, the users would just go with
for (item : pageable.Items)
right away, without checking for HasValue().The spec says it is optional, and I get that, but if we don't take that literally, we could special-case that.
To be extra careful, we could make an option for that, which you could toggle to Off for the potential services where there is a meaningful distinction.
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 an interesting question. I think I agree with you that Items should just be a
vector<T>
and not aNullable<vector<T>>
.My one concern is that I suspect it is legal for a pageable to return 0 entries for a page even if there are more pages still to come (in other words,
HasPage
is true, butItems
is empty. It is a coding mistake for a customer to treatItems.empty()
as if it was the same asHasPage()
returning false, but it would be an easy mistake for a developer to make. MakingItems
be nullable basically renders that mistake impossible at the cost of a poor developer experience.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.
Hmm, but technically nothing prevents
pageable.Items.HasValue() == false
whilepageable.HasPage() == true
. And I also thought another possible mistake for the user to make - to assume thatItems.Value().size() > 0
ifItems.HasValue() == true
. So, it is complicated, for sure, but maybe we could make it a tiny bit better.Whether the service returns
[]
ornull
/undefined
, we can generate code to hide that from user, in all cases the result will be as if it was[]
.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 a good conversation. To Larry's point, having an empty page (where HasPage = true) is something we'd need to consider keeping the distinction clear on.
I am reminded that the customer can make the same call directly to the service and would have to handle the null or empty case, even outside of the SDK.
The simplest (and easiest to explain) stance is to honor the spec and service behavior as the source of truth. We could try to introduce usability improvements like this as a potential UX win for SDK users, but I am not sure if we potentially lead to further confusion or unintended consequences.
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.
To your point, @antkmsft, the existing hand-written SDKs don't use
Nullable<T>
for the collection: https://github.com/Azure/autorest.cpp/issues/475