[
https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094578#comment-14094578
]
Erik Hatcher edited comment on SOLR-6365 at 8/12/14 7:54 PM:
-------------------------------------------------------------
bq. naming a bunch of params and using it as a reference in queries
+1, and I'll add a bit of interesting historical correlation to Ant's "data
types" http://ant.apache.org/manual/using.html#path
I'd suggest rather than trying to make the params be represented as HTTP query
string fragments (a messy implementation detail, embedded solr usage for
example doesn't need to talk HTTP or query strings), that they be <lst
name="defaults"><str name="param_name">param_value</str></lst> kind of format.
In the spirit of the Ant, maybe something like:
{code}
<paramset id="my_facet_params">
<lst name="defaults">
<str name="facet.field">category</str>
<!-- ... -->
</lst>
</paramset>
{code}
And then request handlers could pick up one or more parameter sets such as
/select?q=query¶mset=my_facet_params (or maybe
¶msets=my_facet_params,.... so they can be in guaranteed order of
evaluation).
was (Author: ehatcher):
bq. naming a bunch of params and using it as a reference in queries
+1, and I'll add a bit of interesting historical correlation to Ant's "data
types" http://ant.apache.org/manual/using.html#path
I'd suggest rather than trying to make the params be represented as HTTP query
string fragments (a messy implementation detail, embedded solr usage for
example doesn't need to talk HTTP or query strings), that they be <lst
name="defaults"><str name="param_name">param_value</str></lst> kind of format.
In the spirit of the Ant, maybe something like:
{code}
<paramset id="my_facet_params">
<lst name="defaults">
<str name="facet.field">category</str>
<!-- ... -->
</lst>
<paramset>
{code}
And then request handlers could pick up one or more parameter sets such as
/select?q=query¶mset=my_facet_params (or maybe
¶msets=my_facet_params,.... so they can be in guaranteed order of
evaluation).
> specify appends, defaults, invariants outside of the component
> ---------------------------------------------------------------
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> The components are configured in solrconfig.xml mostly for specifying these
> extra parameters. If we separate these out, we can avoid specifying the
> components altogether and make solrconfig much simpler. Eventually we want
> users to see all funtions as paths instead of components and control these
> params from outside , through an API and persisted in ZK
> example
> {code:xml}
> <!-- these are top level tags not specified inside any components -->
> <params path="/dataimport" defaults="config=data-config.xml"/>
> <params path="/update/*" defaults="wt=json"/>
> <params path="/some-other-path/*" defaults="a=b&c=d&e=f" invariants="x=y"
> appends="i=j"/>
> <!-- use json for all paths and _txt as the default search field-->
> <params path="/**" defaults="wt=json&df=_txt" />
> {code}
> The idea is to use the parameters in the same format as we pass in the http
> request and eliminate specifying our default components in solrconfig.xml
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
