[Azure Search] Generate code for the Search and ContinueSearch API #5324
Commits on Mar 7, 2019
-
-
-
Removing DocumentSearchResult/SearchResult and their base classes
From now on, for dynamically-typed scenarios, callers of Search need to use DocumentSearchResult<Document> and SearchResult<Document> instead. This will make it easier to transition the implementation of this API to generated code.
-
[Azure Search] Remove FacetResults and HitHighlights types
This is a breaking change to facilitate more generated code in the SDK. Facet results are now typed as IDictionary<string, IList<FacetResult>> and hit highlights as IDictionary<string, IList<string>>.
-
[Azure Search] Clarify serialization capability of SearchContinuation…
…Token Added remarks to the comments for SearchContinuationToken that call out its ability to be serialized to and from JSON.
-
[Azure Search] Generate code for the Search API and its model types
This change introduces new generated code and replaces most custom model class code with generated models, but it does not yet switch over the implementation of Search to use the new generated code.
-
[Azure Search] Simplify how continuation tokens are constructed
This is a temporary step on the way to replacing the custom implementation of Search with generated code. This change streamlines the process of deserializing search results by: - Removing the unnecessary intermediate DocumentSearchResponsePayload class - Moving the logic to build SearchContinuationTokens into DocumentSearchResult - Passing JsonSerializerSettings to the core operation methods instead of passing lambdas Since DocumentSearchResponsePayload is gone, I also took the opportunity to make SearchContinuationTokenPayload a private nested class of SearchContinuationTokenConverter. -
[Azure Search] Replace Search implementation with generated code
Also remove functionality from SearchParameters that isn't used anymore.
-
[Azure Search] Updating session records
Also fixing some Java-isms in a test.
-
[Azure Search] Replace ContinueSearch implementation with generated code
This required some very hacky regexes to customize the generated code, but it works. Also, it's better than having to parse URL query strings to reconstitute a SearchParameters instance, since that would miss custom parameters that can't be modeled in Swagger, like personalization IDs for custom ranking. Ideally we'll find a pattern common to other data plane APIs so we don't have to hack this with regexes for every target language, but it's good enough for now.
-
[Azure Search] Refactor DocumentsOperations & make AutocompleteMode n…
…on-null Also renamed some properties for consistency.
-
-
-
-
