[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478930
]
J.J. Larrea commented on SOLR-183:
----------------------------------
Modest proposal: If one is going to come up with a programmer-facing mechanism
for required parameters (using any of the abovementioned schemes), why not also
make it configuration-facing as well. That is, in solrparams.xml:
<requestHandler name="blah" class="solr.DisMaxRequestHandler">
<lst name="defaults">
<str name="version">2.1</str>
<int name="rows">0</int>
...
</lst>
<lst name="requires">
<str name="q">A query must be specified using the q parameter</str>
<str name="version">This handler depends on version being explicitly
set</str>
</lst>
...
</requestHandler>
RequestHandlerBase would add to the definition and initialization of defaults,
extends, and invariants, a fourth SolrParams called requires. Then when the
init is building the (invariants --> ((request --> defaults) + appends))) chain
with DefaultSolrParams and AppendedSolrParams (delegated to method
SolrPluginUtils.setDefaults), it could interpose a new class RequiredSolrParams
which acts like DefaultSolrParams except it accepts the 'requires' SolrParams
defined in the handler config, which in my proposal defines a param
name/message pair. If a param not found in the target SolrParams is defined in
'requires', the exception is thrown. Otherwise the RequiredSolrParams behaves
similarly to DefaultSolrParams (which it extends) by delegating the request up
the chain, or if no chain is defined returning null.
Depending on what the programmer wants, the RequiredSolrParams could be chained
with just the request params:
(invariants -> ((requires -> request) -> defaults) + appends)
or could be chained with the entire chain as it exists:
requires --> (invariants --> ((request --> defaults) + appends)))
I've attached an illustrative implementation. I must apologize, while it
compiles I have not yet tested it, I am under deadline and have spent too much
time on this today already; I'll try to do so over the weekend, along with the
RequestHandlerBase/SolrPluginUtils implementation. It accepts a requires
SolrParams as described above, with the values interpreted as a Formatter
string. It also has an "always required" mode with a method signature which
accepts a fixed message format string. It also has a convenience method
(temporarily commented out because of method signature clash) which shows how
you can provide custom messages for some parameters but have a stock default
message for others.
I believe this object should be compatible with what Ryan posted, e.g. you
could add implementations for getXXX(param, default) which override the "throw
the exception" behavior it now has.
Anyway, I am open to feedback. Useful? Excessive? Broken? Stupid?
> 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: 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.
