2022-10-23 - CombinedSearchResult for joining multiple SearchResults

Service - Search Results Service - Category Tree Standard

Overview

When creating flow for joining multiple filters together when creating each CategoryNodes filter realized there was a problem connected to decision to solve 2022-03-27 - Search Result Using Child Data in Parent Data by sending subComplexFilters in the parent's FindData request and letting FindData (on a per parent ID basis) pass down requests to child types to receive and process filtered child results.

The parent FindData flow only works for subComplexFilters that are top level in the parent's ComplexFilter, but when we combine multiple filters for categoryNodes we would need to group them into lower levels to ensure logic works correctly, thus breaking the ability to process requiredData that needs subComplexFilters

Considerations

Currently the parent FindData flow requires child subComplexFilters to be top-level, and to only have one instance of that child filter type. We will maintain this rule (so should have validation of submitted filters to ensure this).

When joining filters into one filter we would need to group into lower level groups separated by OR/AND otherwise each filter's top level AND/OR operations will mix with the combining AND/ORs and result in failed filtering.

Sometimes multiple filters will be combined using AND, sometimes OR, sometimes combined so will need grouping structure as well.

Solution

Split filters from different sources into separate filters and handle each separately.

Once each filter is processed it will pass to SearchResult which will FindData, this must also be handled per filter because subComplexFilters need to be extracted from the requests filter at top level and send to FindData.

Once FindData is found we can combine into one set of results. I believe we can combine these at the SearchResult level, and that SortResult does not require any separation of filters, so we will handle this within SearchResult service.

The method of combining multiple filters is very similar to multiple elements in ComplexFilter, so we will copy most of the logic from that flow.

• Each separate filter will have it's own SearchResultMain record and process as normal
• All SearchResults will trigger a Lambda that checks for Operation SearchResult records that combine two SearchResultMain together
• Grouping dictates the order in which SearchResult (standard or operation) join together
• ? Probably save Operation SearchResult's in SearchResultMain, the same tables as standard SearchResults, the searchResultMainId will come from the request so should not collide with standard SearchResultMains, this will allow combining results to be more standardized as the two child datasets could be standard or operation, and cache system works as normal.

Probably have a separate Lambda where we send requests for CombinedSearchResults, we could have one overloaded Lambda that checks the request, which could be good for flows that can receive ether, but the logic will be completely different, if we need a single Lambda in the future we could make one that checks the request and passes to either ProcessSearchResult or ProcessCombinedSearchResult Lambda.

Some SearchResult request properties will be standard across all filters, such as requiredData. Maybe send requestParams per filter.