[
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
