markharwood commented on pull request #1708: URL: https://github.com/apache/lucene-solr/pull/1708#issuecomment-677691691
@jimczi The TL/DR is I think it's going to be too hard to implement the stricter parsing logic. I spoke with @romseygeek and we couldn't see a neat way that the string after the closing `/` could be processed. The parser doesn't allow us to write a handler that behaves differently depending on a flag: #### Eager option - pass everything immediately after closing `/` to the regexp constructor logic. 1) When in strict mode , a simple non-i string is easy to detect and error on. 2) When not in strict mode the non-i string has to then be parsed as a regular clause (along with any boosts). It's not possible for the regex query-building logic to invoke the parser to do this. #### Lazy option - pass only any trailing `i` to the regexp constructor logic This simplifies the regex construction logic but pushes the problem elsewhere - in strict mode, the next clause the parser builds would have to double-check it wasn't immediately preceded by a regex with no whitespace to separate them and throw an error. The parsing framework does not provide such a context that would allow this logic. ### Alternative option We did consider forgetting about `/Foo/i` syntax and opting for the inline syntax commonly supported by regex parsers e.g. `/(?i)Foo/` but this is less well known and more cryptic. ### Summary We felt that the existing lax implementation where `/Foo/iphone` is interpreted as `/[Ff][Oo][Oo]/ OR phone` is not so awful that it warrants the added complexity needed to make it work as we'd ideally want. If there are any smart ideas we're open to them but it looks like a very messy problem. ---------------------------------------------------------------- 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...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
