lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-6365) specify appends, defaults, invariants outside of the component
Date Tue, 12 Aug 2014 19:56:13 GMT

    [ 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&paramset=my_facet_params
(or maybe &paramsets=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&paramset=my_facet_params
(or maybe &paramsets=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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message