Overview

findData for parent searchType wants to use searchResultData from a child search result.

example:

searchType: product, fieldName: maxPrice, will aggregate the maxPrice of sellOffers per product, but only sellOffers that pass the child filter/searchType
searchType: product might have a fieldName that lists sellOfferIds, would be the same as maxPrice but not aggregate, will query all child filter/searchType results to build it's data

option 1: use ParentDataId table

parent searchResult will not begin processing until all child searchResults complete
child searchResult automatically records into ParentDataId links between child searchResultData and parent id
findData for each parent dataId can query ParentDataId table to find matching child records
aggregate would need to be done using new logic in parents findData flow (maybe can create lib to do this)

must always add all ParentDataId fields to child request to build ParentDataId data ready for any parent request made
aggregate may take more queries/code
will data used to aggregate value be cached?

perhaps not need ParentDataId/child SearchRequest code
instead we only process complexFilter for initial request, which will split out the filtering into child filters
for each dataId found we also send in requestProperties the filter for the child searchResult
each dataId creates it's own child searchResult request, adding in it's dataId as one of the filter elements
record awaitingStep, perhaps aggregated findDataSortedRequest to receive response for each dataId

uses standard code eg for aggregates
could simplify searchResult logic, no longer need code that handles child searchResults and ParentDataId?

a lot more messages and child searchResultMain records, one for each parent dataId
all dataIds will share all elements of the child searchResult request, excluding the added dataId element
more queries and lambda invocations to prepare child searchResultMain for each parent
messages to findData will be larger as will include the child datas request
only top level child filters can be handled, must enforce this rule in requests
only one child filter per type can be handled, must enforce this rule in requests

could have standard way of marking a field as needing to send a certain child filter from the main filter in it's findData requestProperties, so we do not need to add this to the original requests requestProperties, and only send it in the findData message for that fieldName, not for other fieldNames