Looking back at SOLR-183 I see JJ had a comment about this...
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.
to which ryan replied...
I don't follow the strict/not strict logic to getFieldParam... If you
don't want strict checking, use the normal SolrParams, if you do, use
RequiredSolrParams
...it seems like there was maybe a missunderstading there about what JJ
was trying to say, ... either that or i'm really confused.
Is there a way to do what I'm trying to do with RequiredSolrParams right
now that i'm just not realizing, or should we add something to achieve
this?
To be honest, at the time I did not understand the semantics of field
params that fall through to the non-field use case.
I imagined you would have handle this case with something like:
String v = params.getFieldParam(f,SolrParams.FACET_DATE_END );
if( v == null ) {
v = required.getParam( SolrParams.FACET_DATE_END );
}
I think it makes sense to change RequiredSolrParams so that you get the
same behavior with:
v = required.getFieldParam( f, SolrParams.FACET_DATE_END );
ryan
