[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=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=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
