We have quite a few, including MapSolrParams which seems to explicitly defy
the contract of SolrParams being a multimap...
Has anyone spent any time considering if we really need all these variants:
- AppendedSolrParams
- DefaultSolrParams
- DocRowParams
- MapSolrParams
- ModifiableSolrParams
- MultiMapSolrParams
- RequiredSolrParams
- SolrQuery
- VersionedParams
Additionally there seem to be 3 places where we create anonymous subclasses
of SolrParams...
Most of these seem to have some angle or additional fields, so they aren't
useless per-se but it does make it hard to reason about the behavior of a
method that accepts SolrParams... for example RequestUtil.processParams()
has the suspicious code:
public static void processParams(
SolrRequestHandler handler,
SolrQueryRequest req,
SolrParams defaults,
SolrParams appends,
SolrParams invariants) {
boolean searchHandler = handler instanceof SearchHandler;
SolrParams params = req.getParams();
// Handle JSON stream for search requests
if (searchHandler && req.getContentStreams() != null) {
Map<String, String[]> map = MultiMapSolrParams.asMultiMap(params, false);
if (!(params instanceof MultiMapSolrParams || params instanceof
ModifiableSolrParams)) {
// need to set params on request since we weren't able to access
the original map
params = new MultiMapSolrParams(map);
req.setParams(params);
}
This seems to A) possibly fail to restrict defaults and appends to the
actual subclasses that are associated with that functionality (and if that
is not a good idea, why do we have them?), and B) discard the request
parameters if someone uses anything other than the expected two subclasses
of SolrParams in the request.
Has this been considered before?
Archives search only brought up my previous irritations with SolrParams
implementations...
https://lists.apache.org/thread/tkoj75z736x1nzotgh2xsn7wdnnsoc8g
-Gus
--
http://www.needhamsoftware.com (work)
https://a.co/d/b2sZLD9 (my fantasy fiction book)
