[Azure Search] Generate code for the Search and ContinueSearch API #5324
Conversation
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
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.
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>>.
…Token Added remarks to the comments for SearchContinuationToken that call out its ability to be serialized to and from JSON.
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.
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.
Also remove functionality from SearchParameters that isn't used anymore.
Also fixing some Java-isms in a test.
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.
…on-null Also renamed some properties for consistency.
|
sign-off |
UD1412
approved these changes
Mar 8, 2019
updixit
approved these changes
Mar 8, 2019
brjohnstmsft
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Corresponding Swagger PR: Azure/azure-rest-api-specs#5315 (comment)
This change replaces a bunch of custom code with generated code, specifically for the Search API, and its companion paging method, ContinueSearch.
There are some breaking changes:
DocumentSearchResult<Document>andSearchResult<Document>.IDictionary<string, IList<FacetResult>>and hit highlights asIDictionary<string, IList<string>>.We have already bumped the major SDK version in anticipation of these breaking changes.
Big thanks to @mhko who did the exploratory work for generating the Search and ContinueSearch APIs.
FYI @arv100kri @Yahnoosh @natinimni @updixit @ishansrivastava90 @ruiqiding