lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <ryan...@gmail.com>
Subject Re: semantics of RequiredSolrParams.getFieldParam("field","param")
Date Thu, 05 Jul 2007 21:36:20 GMT
> 
> 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



Mime
View raw message