magibney commented on pull request #129:
URL: https://github.com/apache/solr/pull/129#issuecomment-853380214


   > ** Current Incorrect Behaviour **
   > If I query a "StrField" type or a text field type Keyword Tokenized, I get 
two different behaviours :
   > sow=false -> it splits on whitespace anyway for StrField, causing 
incorrect results, for Keyword Tokenized texts, it works correctly
   > sow=true -> to split on whitespace independently of the field type, it 
works correctly
   
   This summary is helpful. If starting with a clean slate, perhaps the 
"correct" behavior should be as you've outlined -- but then I would think you'd 
want the same strict "non-splitting" behavior for integer fields. My gut 
reaction is that this is a very unusual use case (configuring a StrField or 
integer field as `qf`). In fact, a strong argument in principal for "strict" 
non-splitting behavior would be to effectively discourage this kind of 
configuration in the first place!
   
   Ultimately though I think I'm converging on agreement with 
https://github.com/apache/solr/pull/129/files#r638071458 ... tbh I'm having a 
hard time imagining a use case where the configuration in question (or its 
current behavior) would be desirable; but assuming there may be such use cases 
already in place, this change could surely disrupt them.
   
   Perhaps the fact that keyword-tokenized text fields currently work 
"correctly" (as defined above) could be employed to address this issue going 
forward for certain use-cases, rather than changing existing behavior? 
Keyword-tokenized text would also seem more appropriate to the `edismax` 
use-case, by providing analysis for text _normalization_ (the lack of which 
strikes me as the most unusual aspect of configuring StrField `qf`). 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to