[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479175
]
J.J. Larrea commented on SOLR-183:
----------------------------------
I was unfortunately not very clear, and confounded 2 things, an enhanced
programmer-facing API, based on yours, for request-handler developers, and
secondly an API supported by RequestHandlerBase for request handler
configurators.
>From the programmer perspective, my contribution is simply to allow
>specification of either a global error format, and/or a parameter-specific
>definition of which parameters are required and how missing required
>parameters should be reported. It has no negative impact on the use case you
>desire, and the modified code should pass all the exists/doesn't exist tests
>in your RequiredSolrParamTest.java; if you slapped in your method signatures
>that return 400 SolrExceptions on bad type conversion, either into my
>RequiredSolrParams or SolrParams as I suggested above, it should pass all the
>tests, and if not, I will make it so.
For example,
Map<String,String> rmap = new HashMap<String, String>();
rmap.put( "q" , "A query must be specified using the q parameter" );
rmap.put( "version" , "This handler depends on version being explicitly
set" );
SolrParams required = new RequiredSolrParams( params, new MapSolrParams(
rmap ) );
This is similar to the suggestion in Hoss' first comment on this issue.
The other use-case is for the RequestHandler configurator. There are a lot
more of those than RequestHandler programmers. My model is that they are
defining request handling service APIs by defining <requestHandler>s in
solrconfig. Those APIs can be used by other web programmers in the
organization, who will make mistakes in calling the API, as we all do.
RequestHandlerBase gives RequestHandler configurators three options for
controlling the API, the invariants defaults and appends. I am simply
proposing a 4th option to define which parameters are required, and the error
message that should be returned in the case it is missing. It's not a
comprehensive parameter validation mechanism, but such would be beyond the
scope of SOLR. However as someone who is actively creating RequestHandler APIs
for other programmers in my organization, using custom code when necessary but
avoiding it whenever possible, I think it might be useful.
And in no way does this second use-case by itself allow RH configurators to
override the first use-case requirements set up by RH programmers, unless the
RH programmers make explicit provision to do so. For example, by chaining a
DefaultSolrParams with params derived from a <requestHandler> requires list in
front of a default MapSolrParams like the above, the RH programmer allows the
RH configurator to add new requirements, and externally change the error
strings for programmer-supplied requirements, but not to remove
programmer-supplied requirements.
Anyway, hopefully I've better communicated the idea this time.
> 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
>
>
> 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.
