Change Details

Currently we rely on doing one search per topic, which is expensive and we'll want to move away from it at some point. Once we do a joint search for all topics the user selected, we'll need a way to tell which search result is about which topic. The nicest way would be to fetch this data from the ElasticSearch index; maybe it's possible to do that as an extension to the search API, maybe it would require switching to raw CirrusSearch queries (in which case we might want to compare alternative options, like stashing the topic in page_props).

Currently we rely on doing one search per topic, which is expensive and we'll want to move away from it at some point. Once we do a joint search for all topics the user selected, we'll need a way to tell which search result is about which topic. The nicest way would be to fetch this data from the ElasticSearch index; maybe it's possible to do that as an extension to the search API, maybe it would require switching to raw CirrusSearch queries. In the longer term this might be useful for other things as well (e.g. store the task type definitions in ES as well and fetch them in a similar way so we can also collapse type searches into one).

Currently we rely on doing one search per topic, which is expensive and we'll want to move away from it at some point. Once we do a joint search for all topics the user selected, we'll need a way to tell which search result is about which topic. The nicest way would be to fetch this data from the ElasticSearch index; maybe it's possible to do that as an extension to the search API, maybe it would require switching to raw CirrusSearch queries (in which case we. In the longer term this might want to compare alternative options,be useful for other things as well (e.g. like stashingstore the task type definitions in ES as well and fetch the topic in page_propsm in a similar way so we can also collapse type searches into one).