forked from Azure/azure-rest-api-specs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Hub Generated] Review request for Microsoft.Azure.Search.Service to …
…add version 2017-11-11-preview (Azure#5410) * [Azure Search] Make connectionString create-only to fix validation warning This change is just to satisfy Swagger spec validation; It has no effect on code generation (at least for C#). * [Azure Search] Fix various Swagger validation errors This is our first major push towards making searchservice.json pass all Swagger validation. The validator found several issues that this change fixes: - "Extensible enums" were being modeled incorrectly. On the wire, they are just strings, but we were modeling them as objects with a "name" property. This reflected the generated code, but not the wire format. The solution is to model them as proper enums in the Swagger. This causes new validation errors, since these enums should be open-ended, but that's an issue with the validator not understanding "extensible enums"; it's not a problem with our spec per se. - Properties of Skill were marked as "required", when they were being omitted or set to null in examples. This is because these properties actually appear to be optional from the point of view of the REST API, so now we model them as such. - "documentdb" was deprecated as a DataSourceType, but not replaced with "cosmosdb" in the examples. This is now fixed. - The example for "Get Indexer Execution Status" included properties in the response that aren't modeled in the Swagger. These properties actually do appear on the wire, but they shouldn't and will be removed in a future API version. In the meantime, I have removed them from the example. * [Azure Search] Applying consistent JSON formatting to Swagger spec * [Azure Search] Make inputs/outputs properties of Skill required It turns out these properties are required by the API. Also replaced the deprecated NER skill in examples. * [Azure Search] Standardize formatting of JSON examples * [Azure Search] Rolling back NamedEntityRecognition example update * [Azure Search] Make Swagger spec accurately reflect the semantics of Field Before this change, the descriptions in the Swagger for the Field type did not accurately describe the semantics of the Azure Search REST API, particularly around what the default values of the searchable, filterable, sortable, and facetable properties were. Instead, they reflected the defaults of our custom implementation of Field in the .NET SDK. This change corrects the descriptions to accurately reflect the REST API. It also adds more detail in anticipation of generating REST API documentation from the Swagger (which we don't currently do). A few other changes to Field are related to code generation: - Removed the x-ms-external flag so that AutoRest can generate this type. - Removed x-nullable: false and x-ms-client-name since they again reflect only the custom .NET code and not the desired REST API semantics. - Added regex transform rules to readme.md so that we can keep some of our custom code for Field in .NET purely for backward compatibility purposes. Our intention going forward for other languages is to rely solely on code generation for the Field type.
- Loading branch information
1 parent
27af2f4
commit 5cf04ee
Showing
33 changed files
with
1,273 additions
and
765 deletions.
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
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
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
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
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
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.