At 11:30 PM -0800 2/21/07, Ryan McKinley wrote:
>The question is do we want to add *another* parameter to say "don't
>parse the ; sort even if i don't specify the sort parameter"?
>
>Yes, testing the existence/non-existence of a param is not great - but
>I don't think adding another field is worth it for something this
>small that *can* be accomplished with an empty (or explicit
>'sort=score') parameter. It seems like the effort involved in
>explaining a new parameter is more then saying "if you don't want ';'
>to get parsed as a sorting parameter, make sure to specify a 'sort'
>parameter."
Ryan, I agree with you that adding an extra control parameter is overkill for
something so small.
Another question is whether the ; behavior is considered deprecated with the
introduction of sort=, or maintained ad infinitum as a parallel approach for
sort specification (for StandardRH only, or perhaps for DisMaxRH too if we
introduce a parameter to control the q escaping and ; is not escaped).
If deprecated, then I think version= may be the most elegant way to do that,
per my prior email.
If parallel, then I agree that existence/nonexistence would be the simplest way
to toggle the behavior (from a user perspective). My "uncool" comment was, er,
uncool, but the motivation was that AFAIK in no other place does SOLR make this
distinction, an assumption based on SolrParams not having an API to test for
param existence and being explicitly coded around nonexistence and null being
equatable; meanwhile elsewhere in the code (e.g. parseSort) null and "" are
equated.
So this would constitute a policy change, and one that required a fundamental
(albeit small) API and logic change; for example, in MapSolrParams and
MultiMapSolrParams, one would need to convert present but null-valued Map
entries into "" or String[]{}, respectively, either upon initialization or on
demand in get(key), so things like DefaultSolrParams and the various
SolrParams.getXXX(key, default) can continue to use null as a flag for
not-present. Alternately one could introduce an exists(key) method, but then
every one of those checks for null indicating "use the default" would need to
be changed so null becomes a first-class citizen. Or something like that.
So while such a global policy change would probably be a good thing in the long
run, I fear it's not trivial (unless once again I missed something).
- J.J.
