Add CustomEntityLookupSkill#10832
Conversation
|
Swagger pipeline restarted successfully, please wait for status update in this comment. |
|
Azure Pipelines successfully started running 1 pipeline(s). |
azure-sdk-for-java - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
Azure CLI Extension Generation - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-go - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-net - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-python - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-sdk-for-js - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
azure-resource-manager-schemas - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
Trenton Generation - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
lmazuel
left a comment
There was a problem hiding this comment.
From a Swagger perspective LGTM
heaths
left a comment
There was a problem hiding this comment.
I know a precedent is set with so many nullable properties, but wouldn't it save bandwidth to just not serialize them across the wire?
| }, | ||
| "caseSensitive": { | ||
| "type": "boolean", | ||
| "x-nullable": true, |
There was a problem hiding this comment.
There are a lot of x-nullable fields. Can you just not send them when null? Is there an advantage to sending, for example, "caseSensitive": null and similar for everything that isn't explicitly set?
specification/search/data-plane/Azure.Search/preview/2019-05-06-preview/searchservice.json
Outdated
Show resolved
Hide resolved
| "caseSensitive": { | ||
| "type": "boolean", | ||
| "x-nullable": true, | ||
| "description": "Determine if the alias is case sentitive." |
There was a problem hiding this comment.
You should document the default either in the description or in swagger. Note that the generators won't (or at least shouldn't) generate code for the default since that creates a tight coupling across versions. Defaults must be applied at the service.
| } | ||
| ], | ||
| "properties": { | ||
| "defaultLanguageCode": { |
There was a problem hiding this comment.
Based on other skills, this should be "x-nullable": true since you send the others will a null value, or will that not be the case here? Better not to waste bandwidth with null values if there's no benefit.
| }, | ||
| "entitiesDefinitionUri": { | ||
| "type": "string", | ||
| "description": "Path to a JSON or CSV file containing all the target text to match against." |
There was a problem hiding this comment.
Any auth requirements that should be documented? E.g. "Must be publicly accessible via a GET query."
| "url": "https://docs.microsoft.com/en-us/azure/search/cognitive-search-skill-custom-entity-lookup" | ||
| }, | ||
| "description": "A skill looks for text from a custom, user-defined list of words and phrases." | ||
| }, |
There was a problem hiding this comment.
No required values? I would assume that at least the inline or URI parameters need to be specified. You might add that to the description. Swagger can actually require one of the two, but I'm not sure our generators would handle that.
brjohnstmsft
left a comment
There was a problem hiding this comment.
This appears to be targeting the wrong API version. We shouldn't be making changes to the 2019 specs anymore.
|
Azure Pipelines successfully started running 1 pipeline(s). |
azure-sdk-for-python-track2 - Release
No readme.md specification configuration files were found that are associated with the files modified in this pull request, or swagger_to_sdk section in readme.md is not configured
|
|
Azure Pipelines successfully started running 1 pipeline(s). |
specification/search/data-plane/Azure.Search/preview/2020-06-30-Preview/searchservice.json
Outdated
Show resolved
Hide resolved
| }, | ||
| "globalDefaultCaseSensitive": { | ||
| "type": "boolean", | ||
| "x-nullable": true, |
There was a problem hiding this comment.
Why is this property both optional and nullable? What is the difference between the key/value not being present and the key/value being present with a null value?
There was a problem hiding this comment.
For some reason all my replies seem gone...
The key/value not being present and key/value being present with a null value don't make a difference from the backend service perspective. Do you recommend me to remove "x-nullable" here and for all other similar fields?
There was a problem hiding this comment.
I would recommend for the service to not send the null value on the wire if that is the case. If the service isn't actually sending null on the wire, then the x-nullable annotation should be removed.
If the service is sending a null value on the wire, it is unfortunate, but it has to be marked as x-nullable in the swagger. At the end of the day, the swagger has to describe what how the service is behaving regardless of if it is following best practices or not...
There was a problem hiding this comment.
I recently had this question with @bleroy and @brjohnstmsft. Not only is it a waste of bandwidth, but it has been causing problems since not nearly everything that should be marked x-nullable is, and our generators do care that it's authored correctly. Alas, it sounds like the OData library they use does this. Still, is there some way to get that fixed, or opt into a more wire-friendly serializer? I know Newtonsoft.Json won't send explicit nulls by default, so it seems OData is overriding that. Why, I can't imagine.
There was a problem hiding this comment.
I know Newtonsoft.Json won't send explicit nulls by default, so it seems OData is overriding that.
OData .NET has its own serializer; It's not based on JSON.NET.
Trying to fix this would be a potentially costly change for us (either swapping out OData's serializer, or forking the library and fixing it), and would be hard to justify given our other priorities. You should proceed on the assumption that the service behaviour isn't going to change.
specification/search/data-plane/Azure.Search/preview/2020-06-30-Preview/searchservice.json
Outdated
Show resolved
Hide resolved
specification/search/data-plane/Azure.Search/preview/2020-06-30-Preview/searchservice.json
Show resolved
Hide resolved
|
Azure Pipelines successfully started running 1 pipeline(s). |
specification/search/data-plane/Azure.Search/preview/2020-06-30-Preview/searchservice.json
Outdated
Show resolved
Hide resolved
|
Azure Pipelines successfully started running 1 pipeline(s). |
Remove unnecessary x-nullable
|
Azure Pipelines successfully started running 1 pipeline(s). |
…0-Preview/searchservice.json Co-authored-by: Heath Stewart <heaths@outlook.com>
|
No pipelines are associated with this pull request. |
|
ADO seems stuck, second to last commit was green, and last commit was just string replace, merging |
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Contribution checklist:
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.
If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.
Please follow the link to find more details on PR review process.