I agree that things are needlessly complex, and could definitely be
simplified. (hopefully down to one class?)'
- Houston
On Wed, Apr 3, 2024 at 9:54 AM Gus Heck <gus.h...@gmail.com> wrote:
> Ah, just noticed that I missed the ! symbol when I read that code, none the
> less things are still complex
>
> On Wed, Apr 3, 2024 at 10:50 AM Gus Heck <gus.h...@gmail.com> wrote:
>
> > 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)
> >
>
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>
