[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482455
]
J.J. Larrea commented on SOLR-183:
----------------------------------
I totally agree with Ryan that the question I raised about the value of
specifying required params in solrconfig.xml RH definitions should be separated
from this simpler programmer-API case. I will speak no more of that on
SOLR-183.
Ryan, after looking at your patch #4 I've had a change of heart about the
getRequiredXXX approach. To do it properly would require reduplication of
every method signature, e.g. getFieldInt() and so forth, and wouldn't make any
use of the bottleneck imposed by get/getParams. Hoss' decorator approach
coupled with your improved error handling automagically makes everything work
with a trivial subclass.
This time I implemented and tested everything (attachment #5).
RequiredSolrParams is kept as a freestanding class which can be externally
instantiated, but is also returned by a SolrParams.required() convenience
method so we could stash a reference if desired, e.g.
params.required().getInt("xxx")
params.required().getBoolean("yyy")
(but the wasted cycles and amount of garbage created from allocating a new one
is pretty trivial, so perhaps it's best not to add a slot to SolrParams)
In the bottleneck approach the inline-default methods e.g. getBool("xxx", true)
will fail when called on requires - but I think that is not such a bad thing.
Could be fixed if so desired with a _get().
One open question is getFieldParam: Should the semantics of
required.getFieldParam("facet.limit", "abc") be to fail if the parameter is not
supplied for the field (e.g. f.abc.facet.limit), or not supplied for either the
field or as a general default (e.g. facet.limit)? In the former case we don't
need to override getFieldParam. I can't think of a reason that one would want
to require explicit field values and disallow general values, but perhaps
someone else could, and a 'field strictness" flag should be supplied in the
RequiredSolrParams constructor. For the moment I made it non-strict, but put
in a public value allowing that to be controlled.
I changed the order of operations in SolrParamTest so it starts at the simplest
cases (present and non-required and inline defaults), then malformed values,
then required values. I added the fall-through case for getFieldXXX. I also
started some tests of DefaultSolrParams, to be extended to to
AppendedSolrParams (getParams needs testing as well).
> add getRequiredParameter() to SolrParams
> ----------------------------------------
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
> Reporter: Ryan McKinley
> Priority: Trivial
> Attachments: RequiredSolrParams.java, SOLR-183-required-param.patch,
> SOLR-183-required-param.patch, SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
