[
https://issues.apache.org/jira/browse/SOLR-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533090#comment-13533090
]
Yonik Seeley commented on SOLR-4197:
------------------------------------
This is why "defType" stands for "default type" - it's only the default and may
be overridden.
Adding a space would disable recognition of localParams.
For example, when sending "q" through to Solr, construct it like so:
"q" = " " + userQuery;
Or you could specify the query type of "q" using localParams and put the user
query in "qq":
q={!edismax v=$qq}
qq=hello there
> EDismax allows end users to use local params in q= to override global params
> ----------------------------------------------------------------------------
>
> Key: SOLR-4197
> URL: https://issues.apache.org/jira/browse/SOLR-4197
> Project: Solr
> Issue Type: Bug
> Affects Versions: 3.5, 3.6, 4.0
> Reporter: Peter Wolanin
>
> Edismax is advertised as suitable to be used to "process advanced user input
> directly". Thus, it would seem reasonable to have an application directly
> pass user input in the q= parameter to a back-end Solr server.
> However, it seems that users can enter local params at the start of q= which
> override the global params that the application (e.g. website) may have set
> on the query string. Confirmed with Erik Hatcher that this is somewhat
> unexpected behavior (though one could argue it's an expected feature of any
> query parser)
> Proposed fix - add a parameter (e.g. that can be used as an invariant) that
> can be passed to inhibit Solr from using local params from the q= parameter.
> This is somewhat related to SOLR-1687
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
