[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[
https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025475#comment-14025475
]
Hoss Man commented on SOLR-6113:
bq. ...so for your example q=Mission: Impossibleuf=* -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:
Impossibleuf=-*}} ... 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 CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[ https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021161#comment-14021161 ] Eyal Zaidman commented on SOLR-6113: Please excuse my continued confusion, I'm still a bit new to the technical aspects of this feature - I assumed Jan's suggestion was referring to excluding the field name for an *existing* field specified in uf, so for your example q=Mission: Impossibleuf=* -Mission would indeed search for just Impossible, because there is a Mission field/alias defined. Yonik was replying as to why edismax would not throw an exception when uf disallows something, and that seems very reasonable. Are you referring to the same use case as above, where Mission is not a field ? meaning I specify something in uf that isn't a field or an alias? 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 CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[
https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019356#comment-14019356
]
Hoss Man commented on SOLR-6113:
bq. I like the idea of removing just the field name, because I agree it gives a
better result when I look at it from the permission use case scenario
I think you are overlooking the designed usecase: colons appearing in natural
text should be treated as regular text *unless* they are explicitly noted as
special via the uf option.
As yonik pointed out in some recent examples on the mailing list, if a user
searches for {{Mission: Impossible}} we should not ignore the {{Mission}}
portion of the query string if there is no Mission field name and no
explicitly configured Mission field alias.
the default assumption is that the query string is raw query words -- only if
the uf options tell us to treat some text as special (either a field name
or a field alias) should it be treated as special syntax to mean search in
this field or serach against this field alias
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 CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[ https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010943#comment-14010943 ] Eyal Zaidman commented on SOLR-6113: I like the idea of removing just the field name, because I agree it gives a better result when I look at it from the permission use case scenario - you get to search where you're allowed, and there's a chance your data is in the default search field. A literal search with the field name in that scenario would likely suffer from the original issue - there is very little chance the field name exists, as the user did not intend to look for it. I also agree that it's important to provide feedback that search results have been changed, but it seems to me if the search client is adding a uf restriction, it should be the clients responsibility to inform the end user about that restriction ? or at least I can't come up with a good way for Solr to do that. 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 CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[
https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009465#comment-14009465
]
Jan Høydahl commented on SOLR-6113:
---
It is actually by design, if you e.g. disallow all fielded search with
{{uf=-*}} then eDismax will not interpret the x:y as field and value but as a
valid query for literal x y. Some languages use : as separator, e.g. swedish
will write {{FN:s}} (meaning UN's). The same approach is taken when some field
names are disallowed.
But I see that it can be confusing for people who indend to search a field, it
would be better if Solr could give a feedback that fielded search is not
allowed and that it falled back to literal matching.
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: Bug
Components: query parsers
Reporter: Liram Vardi
It seems that Edismax User Fields feature does not behave as expected.
For instance, assuming the following query:
_q= id:b* user:Anna CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[ https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009681#comment-14009681 ] Eyal Zaidman commented on SOLR-6113: I'm a little confused by that behavior, assuming I understand the technical details. The real world scenario uf is trying to address is disallowing or restricting search in some fields, so for example if I wanted to implement a permissions scheme, I could tell it -restrictedField and it would not search there. By treating that search as a literal (presumably because we can't detect whether the user meant a fielded search or a Swedish term, exactly matching a SOLR field name) we're preferring the less common to rather esoteric (IMO) scenario. Adding to that Liram's comment about the relation to SOLR-2649, the default operator behavior could make this even worse, where instead of OR you get an AND behavior, and all searches fail due to forcing a non-existent literal match. Do you think it would make sense to add functionality that removes that part of the search query instead of escaping it ? We could of course make some flag for preserving the old behavior in case someone finds it useful. Could you point us in the right direction to do it if so ? We'd be happy to attempt a patch 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: Bug Components: query parsers Reporter: Liram Vardi It seems that Edismax User Fields feature does not behave as expected. For instance, assuming the following query: _q= id:b* user:Anna CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[ https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009733#comment-14009733 ] Jack Krupansky commented on SOLR-6113: -- Better doc for the intended behavior would help, at least a little. At least we could point people to a clear description of what actually happens. 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: Bug Components: query parsers Reporter: Liram Vardi It seems that Edismax User Fields feature does not behave as expected. For instance, assuming the following query: _q= id:b* user:Anna CollinsdefType=edismaxuf=* -userrows=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
[jira] [Commented] (SOLR-6113) Edismax doesn't parse well the query uf (User Fields)
[
https://issues.apache.org/jira/browse/SOLR-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010443#comment-14010443
]
Jan Høydahl commented on SOLR-6113:
---
Suggestion for improvements welcome. In my opinion, simply discarding the whole
term is also very confusing. Imagine {{uf=-titleq=title:java language}} - as
we're now you will require the three words title, java, language. If we remove
the first term we'll match all docs with language, clearly not the intention.
A perhaps better solution could be to search literally for the string
title:java instead of breaking it into two?
Alternatively, disregard the field part, but let the value part stay and be
subject to qf or df. However, that could be confusing too, if the user won't
get any feedback whatsoever that his query term java was actually not
restricted to title only.
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: Bug
Components: query parsers
Reporter: Liram Vardi
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 CollinsdefType=edismaxuf=* -userrows=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
