[ https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025475#comment-14025475 ]
Hoss Man commented on SOLR-6113: -------------------------------- bq. ...so for your example "q=Mission: Impossible&uf=* -Mission" would indeed search for just Impossible, because there is a Mission field/alias defined. there isn't a "Mission field/alias defined" in your example, there is an explicit exclusion saying that even if "Mission" is a real field, users should _not_ be allowed to query against it directly. By definition in a situation like that, we have to assume that a user who includes "Mission:" in their query string wants to query for the literal word -- because there is no reason to assume they know about the uf exclusions. a more straight forward way to think about it would probably be in the much simpler usecase where no user field queries are allowed: {{q=Mission: Impossible&uf=-*}} ... hte behavior of that query should be the same regardless of whether there is a real field named "Mission" in the index or not -- it should search for "Mission:" and "Impossible" in the configured qf fields. In general, your suggestion seems to be looking at "uf" from a "permissions" standpoint, and thinking that if you have not granted the user permission for something to do something, you should error/ignore the user if they try. But that viewpoint assumes the user *knows* what permissions they have and can understand why you would hide stuff from him if he's naughty and asks for something he shouldn't. that's not really the typical situation. The design is built around the idea that some field names/aliases might be "special" and if the user asks for them we do something special (ie: query directly against a particular field / set of fields) ... but we should not assume that just because the user has a colon character in their query string that means they were trying to take advantage of that feature on a field/alias and ignore them if that field really does exist but is not "special" To draw the inevitable comparison with google: there are special {{foo:}} syntax options you can use like {{inurl:bar}} and {{site:bar.com}} but that doesn't mean that if you use a colon with something that is *not* a special syntax option that google just ignores the words before the colons -- regular old text that happens to contain a colon in it just searches for that text. > Edismax doesn't parse well the query uf (User Fields) > ----------------------------------------------------- > > Key: SOLR-6113 > URL: https://issues.apache.org/jira/browse/SOLR-6113 > Project: Solr > Issue Type: Improvement > Components: query parsers > Reporter: Liram Vardi > Priority: Minor > Labels: edismax > > It seems that Edismax User Fields feature does not behave as expected. > For instance, assuming the following query: > _"q= id:b* user:"Anna Collins"&defType=edismax&uf=* -user&rows=0"_ > The parsed query (taken from query debug info) is: > _+((id:b* (text:user) (text:"anna collins"))~1)_ > I expect that because "user" was filtered out in "uf" (User fields), the > parsed query should not contain the "user" search part. > In another words, the parsed query should look simply like this: _+id:b*_ > This issue is affected by a the patch on issue SOLR-2649: When changing the > default OP of Edismax to AND, the query results change. -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org