alessandrobenedetti edited a comment on pull request #129: URL: https://github.com/apache/solr/pull/129#issuecomment-857805113
Making an update here to understand the potential next steps. So I think we agree that: 1) if you configure a StrField in the QF and you configure sow=false, currently the parameter is ignored, you split by whitespace and you don't match your multi terms (it is like we use a query time tokenization, not in line with the expected invisible query time keyword tokenization of the StrField.) This is incorrect and gets you zero results when you shouldn't 2) the StrField instance of condition is not a solution you like, so we won't approve the pull request in the current state, N.B. I am completely fine with this. My objective here is to solve a problem, I am not in love with any specific solution. So next steps: 3) it seems we want to "discourage" the usage of StrField in QF with an inconsistent behaviour (in comparison with a text field with the same keyword tokenization analysis). Should we then explicitly raise an error if the user passes a StrField (maybe all non-textual fields) in QF? OR 4) should we remove the StrField type completely? we can leave the schema.xml back-compatible, but always use text fields for textual information server-side (I think it's the same approach that Elasticsearch uses and it makes sense to me) OR 5) just ignore this issue? I am not a fan of this OR 6) any other idea? super happy to explore other options -- 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
