[
https://issues.apache.org/jira/browse/SOLR-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471624
]
Hoss Man commented on SOLR-109:
-------------------------------
Thorsten: i finally got a chance to look at this, but i'm not seeing how it
achieves what you described ... this patch only seems to add a new
"substitution" block to the init params for request handlers, which are then
used as defaults in front of hte invariants and the other defaults -- but there
doens't seem to be any actual variable substitution.
(were some files left of of the patch perhaps?)
what i was suggesting in that email thread was that SolrQueryParser.parser
itself could have a string preprocessing step it calls prior to calling
super.parse where anything that looks like a variable (ie: ${foo.bar}) could be
repalced by a SolrParam of the same name -- specified using a new
SolrQueryParser.setSubstitutionSOlrParams(SOlrParam params). the request
handlers would call that using some SolrParams they got from the init params
(no need to put those params in the main bundle of request params)
> variable substitution in lucene query params
> --------------------------------------------
>
> Key: SOLR-109
> URL: https://issues.apache.org/jira/browse/SOLR-109
> Project: Solr
> Issue Type: New Feature
> Reporter: Thorsten Scherler
> Attachments: SOLR-109.diff
>
>
> Allowing variable substitution in the lucene query params seems pretty slick
> ... a more general solution might be to modify the SolrQueryParser
> directly to have a new "void setParamVariables(SolrParams p)" method.
> http://marc.theaimsgroup.com/?t=116712376400001&r=1&w=2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
