Detach SearchPhases from AbstractSearchAsyncAction #23118
Conversation
Today all search phases are inner classes of AbstractSearchAsyncAction or one of it's subclasses. This makes unittesting of these classes practically impossible. This commit Extracts `DfsQueryPhase` and `FetchSearchPhase` or of the code that composes the actual query execution types and moves most of the fan-out and collect code into an `InitialSearchPhase` class that can be used to build initial search phases (phases that retry on shards). This will make modification to these classes simpler and allows to easily compose or add new search phases down the road if additional roundtrips are required.
s1monw
added
:Search/Search
…and use SetOnce on lazy initialization
|
@elasticmachine would you bother to test this |
| private final SearchPhaseContext context; | ||
| private final SearchTransportService searchTransportService; | ||
|
|
||
| DfsQueryPhase(AtomicArray<DfsSearchResult> firstResults, |
There was a problem hiding this comment.
Should we call this dfsResults instead of firstResults so its clear what the results contain?
| this.request = request; | ||
| this.shardsIts = shardsIts; | ||
| this.logger = logger; | ||
| // we need to add 1 for non active partition, since we count it in the total! |
There was a problem hiding this comment.
What do you mean by the non-active partition here?
|
@colings86 I pushed new commits to address your comments. |
There was a problem hiding this comment.
This is a great change that introduces unit tests for each phase and simplifies things in a complicated way ;) !
The abstraction for search phase and the chaining are just great and you preserved small optims like query and fetch for single shard query.
Looks fantastic to me.
| }); | ||
| } | ||
| } | ||
| protected SearchPhase getNextPhase(AtomicArray<DfsSearchResult> results, SearchPhaseContext context) { |
| if (hadOne) { | ||
| sb.append(","); | ||
| } else { | ||
| hadOne = true; | ||
| } |
There was a problem hiding this comment.
minor suggestion, feel free to ignore, but maybe StringJoiner would make it easier to read
| this.counter = new CountDown(expectedOps); | ||
| this.onFinish = onFinish; | ||
| this.context = context; | ||
| assert expectedOps <= resultArray.length() : |
There was a problem hiding this comment.
let's make it a hard exception?
| this.context = context; | ||
| this.logger = context.getLogger(); | ||
| assert context.getNumShards() == queryResults.length() : "number of shards must match the length of the query results but doesn't:" | ||
| + context.getNumShards() + "!=" + queryResults.length(); |
There was a problem hiding this comment.
let's make it a hard exception too?
|
@elasticmachine would you bother to test this |
1 similar comment
|
@elasticmachine would you bother to test this |
Today all search phases are inner classes of AbstractSearchAsyncAction or one of it's subclasses. This makes unit testing of these classes practically impossible. This commit Extracts `DfsQueryPhase` and `FetchSearchPhase` or of the code that composes the actual query execution types and moves most of the fan-out and collect code into an `InitialSearchPhase` class that can be used to build initial search phases (phases that retry on shards). This will make modification to these classes simpler and allows to easily compose or add new search phases down the road if additional roundtrips are required.
Today all search phases are inner classes of AbstractSearchAsyncAction or one of it's
subclasses. This makes unittesting of these classes practically impossible. This commit
Extracts
DfsQueryPhaseandFetchSearchPhaseor of the code that composes the actualquery execution types and moves most of the fan-out and collect code into an
InitialSearchPhaseclass that can be used to build initial search phases (phases that retry on shards). This will
make modification to these classes simpler and allows to easily compose or add new search phases
down the road if additional roundtrips are required.