[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Attachment: SOLR-6365.patch changes the order of applying params. the variables defined in the requesthandler will always override initParams 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 Fix For: 5.0, Trunk Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, SOLR-6365.patch, SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler initParams=a/ requestHandler name=/dump2 class=DumpRequestHandler initParams=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6365: - Attachment: SOLR-6365-crappy-test.patch Is this really unresolved at this point? Assuming so, I'll make the comments here but perhaps we should open a new JIRA instead. On a trunk build with the stock Solr example I see initParams path=/update/**,/query,/select,/tvrh,/elevate,/spell,/browse lst name=defaults str name=dftext/str /lst /initParams I changed the df param in my /select requestHandler to: lst name=defaults str name=dfname/str /lst Then when I just issue collection1/select?q=whatever it parses to q=text:whatever rather than q=name:whatever, which is quite surprising. Is this the intended behavior? Or should defaults in the requestHandler override the initParams? Either way we need to do something. Either it's a bug in the current implementation and the defaults section of the individual handler should override the initParams or we should remove the defaults from all the request handlers in the sample solrconfig.xml. The current behavior is disconcerting to someone who hasn't followed this JIRA closely, i.e. almost all of our users. If we remove the defaults section from the request handlers in solrconfig.xml, I think it would be best to make an explicit reference to initParams, we need to give users some clue what's going on here. This assumes that the notion of being able to call out initParams by ID didn't fall by the wayside. But this will make the vexing problem with, say, people who remove the text field from schema.xml and then can't load cores s much easier to fix. Rather than finding all the places that the text field is referenced in solrconfig.xml and change them to something that _is_ in the schema, there'll be just one place to change.. I've attached a test case for the trunk illustrating. I labeled it totally-crappy because it should NOT be used verbatim, it's a miserable hack to illustrate. I changed solrconfig-minimal.xml and schema-tiny.xml and have NOT re-run all tests with those changes and I fully expect those changes will break something. 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 Fix For: 5.0, Trunk Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler initParams=a/ requestHandler name=/dump2 class=DumpRequestHandler initParams=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Attachment: SOLR-6365.patch changed the tag name from paramSet to initParams 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 Fix For: 5.0, 6.0 Attachments: SOLR-6365.patch, SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} was: 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} 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 Fix For: 5.0, 6.0 Attachments: SOLR-6365.patch, SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler initParams=a/ requestHandler name=/dump2 class=DumpRequestHandler initParams=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} was: 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} 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 Fix For: 5.0, 6.0 Attachments: SOLR-6365.patch, SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- initParams name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /initParams {code} other examples {code:xml} initParams name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /initParams requestHandler name=/dump3 class=DumpRequestHandler/
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {code} was: 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {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 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 Fix For: 5.0, 4.11 Attachments: SOLR-6365.patch 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 functions as paths instead of components and control these params from outside , through an API and persisted in ZK objectives : * define standard components implicitly and let users override some params only * reuse standard params across components * define multiple param sets and mix and match these params at request time example {code:xml} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {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 was: 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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 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 Attachments: SOLR-6365.patch 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Attachment: SOLR-6365.patch Fix with testcases. I plan to commit this soon 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 Attachments: SOLR-6365.patch 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {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 was: 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {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 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 Attachments: SOLR-6365.patch 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} !-- use json for all paths and _txt as the default search field-- paramSet name=global path=/** lst name=defaults str name=wtjson/str str name=df_txt/str /lst /paramSet {code} other examples {code:xml} paramSet name=a path=/dump3,/root/*,/root1/** lst name=defaults str name=aA/str /lst lst name=invariants str name=bB/str /lst lst name=appends str name=cC/str /lst /paramSet requestHandler name=/dump3 class=DumpRequestHandler/ requestHandler name=/dump4 class=DumpRequestHandler/ requestHandler name=/root/dump5 class=DumpRequestHandler/ requestHandler name=/root1/anotherlevel/dump6 class=DumpRequestHandler/ requestHandler name=/dump1 class=DumpRequestHandler paramSet=a/ requestHandler name=/dump2 class=DumpRequestHandler paramSet=a lst name=defaults str name=aA1/str /lst lst name=invariants str name=bB1/str /lst lst name=appends str name=cC1/str /lst /requestHandler {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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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=bc=de=f invariants=x=y appends=i=j/ {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 was: 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 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=bc=de=f invariants=x=y appends=i=j/ {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 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=bc=de=f invariants=x=y appends=i=j/ {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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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 was: 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=bc=de=f invariants=x=y appends=i=j/ {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 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6365) specify appends, defaults, invariants outside of the component
[ https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6365: - Description: 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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 was: 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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 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=bc=de=f invariants=x=y appends=i=j/ !-- use json for all paths and _txt as the default search field-- params path=/** defaults=wt=jsondf=_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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org