Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose (and make simpler) configuration of certain solrconfig.xml fields per index-level [JIRA: RIAK-2077] #537

Open
zeeshanlakhani opened this issue Aug 9, 2015 · 2 comments

Comments

@zeeshanlakhani
Copy link
Contributor

as per #358 (comment)

one size does not fit all

and other discussions we've had since, internally, w/ @fadushin @jonmeredith.

This would probably be nice to add via riak-admin updates on a per index-level and/or via API calls, gossiping the changes to other nodes (similar to how search_index/core creation works and can be included in the creation/update process). Of note, http://stackoverflow.com/a/23786869, look at RELOAD and how to expose that property due to restart constraints on the cores.

@Basho-JIRA Basho-JIRA changed the title Expose (and make simpler) configuration of certain solrconfig.xml fields per index-level Expose (and make simpler) configuration of certain solrconfig.xml fields per index-level [JIRA: RIAK-2077] Aug 9, 2015
@Guibod
Copy link

Guibod commented May 31, 2016

So, I'm pretty new to this subject, but I can already point some problems:

  1. As I write a lot, SolR commits tends to happen a lot. A SolR expert friend of mine explained me that any SolR commit invalidate cache (fq queries). I'd like to be able to tweak the commit interval to something that fit my needs, in order to get some advantages of solr cache. He explained me that autowarm is a way to mitigate that, yet we need to be able to set this easily.
    SolrConfig.xml comments on this matter explain that high autoCommit value put risk because of AAE. Well, in my case AAE come second to SolR cache.
  2. I need to use a component (namely Suggester), that requires a block of configuration inside the SolrConfig.xml. That's pretty simple, yet it requires the index to be created first, solrConfig.xml to be updated, and then solr to be reloaded.
    In order to achieve this kind of tuning, i'd suggest Yokozuna to use XML inclusion through Xinclude or Entity Include to distinguish factory settings from custom extra configuration.

@stevegaron
Copy link

I think that the solrconfig.xml should be handle the same way as the schema.xml is. You can basically save you own and you tell the index to use it.

So while creating an index this would work something like this:

# Create the schema
curl -XPUT http://localhost:8098/search/schema/my_custom_schema \
     -H 'Content-Type:application/xml' \
     --data-binary @my_index_schema.xml

# Create the solrconfig
curl -XPUT http://localhost:8098/search/solrconfig/my_custom_solrcfg \
     -H 'Content-Type:application/xml' \
     --data-binary @my_index_solrconfig.xml

# Create the index
curl -XPUT http://localhost:8098/search/index/my_index \
     -H 'Content-Type: application/json' \
     -d '{"schema":"my_custom_schema", "solrconfig": "my_custom_solrcfg"}'

On a side note: Also I really like that core reload command. Coupled with a reindex function, it would make schema changes a breeze to handle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants