cpoerschke commented on PR #2382:
URL: https://github.com/apache/solr/pull/2382#issuecomment-2088667529
Thanks for the notes above, they helped me continue browsing the code to see
how the `Presearcher` fits in and how the various objects are currently put
together.
So with indexing (via `MonitorUpdateRequestProcessor`) and searching (via `
ReverseSearchComponent` which uses `ReverseQueryParser`) both using the
`Presearcher` but the presearcher actually being _stateless_ then I wonder why
there's a shared presearcher and not separate ones for indexing and searching.
Ease of configuration might be a reason? Or could one imagine a scenario where
indexing and searching wish to use different presearcher types or settings?
And then next I looked to understand more on how the
`ReverseQueryParser[Plugin]` and `SimpleQueryParser` objects fit into the
picture. Here I was temporarily a little confused, the `ReverseQueryParser`
seems to do little parsing but more post-processing on the json-to-document
parsing done by `ReverseSearchComponent.documentBatch` previously and
`SimpleQueryParser` seems to wrap the default parser. Okay, but leaving that
side-thought aside, back to the `Presearcher` focus of my session -- if there
wasn't the `ReverseQueryParser[Plugin]` objects then what might own the
`Presearcher` object? Both `MonitorUpdateRequestProcessor` and
`ReverseSearchComponent` need to be configured by neither seems an obvious
owner for a presearcher used by both.
So next then considering the `ReverseSearchComponent` more closely:
* `ReverseSearchComponent.process` jumps out as being a no-op.
* Upon further consideration this appears to be because use-together-with
the `QueryComponent` is assumed, is that correct?
* If the `ReverseSearchComponent` must be used together with the
`QueryComponent` then wondering what's the pros/cons of that versus
`ReverseSearchComponent extends QueryComponent` inheritance instead.
And if the `ReverseSearchComponent` itself and use of it must be configured
e.g. `<arr name="last-components"> <str>reverseSearch</str> </arr>` in the
request handler, then might an alternative be to have a reverse search handler
class (with in-built default components) and with ownership of the presearcher?
```
public class ReverseSearchHandler extends SearchHandler {
private Presearcher presearcher;
@Override
protected List<String> getDefaultComponents() {
ArrayList<String> names = new ArrayList<>(2);
names.add(QueryComponent.COMPONENT_NAME);
names.add(ReverseSearchComponent.COMPONENT_NAME);
return names;
}
@Override
@SuppressWarnings("unchecked")
public void inform(SolrCore core) {
presearcher = ...
}
}
```
All just some thinking-aloud type notes here really, as a next step I'll
probably look further at the `ReverseQueryParser[Plugin]` and
`SimpleQueryParser` classes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
