Alexandre,
I just made this transition, both to SolrCloud and to managed schema.
In QA and Production, you update solrconfig.xml to say the schema is not
mutable:
<schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>
My workflow in development is as follows:
- Start with gettingstarted configuration and downconfig it:
zkcli.sh -z localhost:9983 -cmd downconfig -confdir conf -confname
gettingstarted
- Create a new collection based on that config:
zkcli.sh -z localhost:9983 -cmd upconfig -confdir conf -confname
configname
solr create -c collectionname -confname configname -s 1 -rf 1
- Build a file addfields.json and another deletefields.json that allow me to
add new fields and delete fields.
- Add my fields:
vim addfields.json # Add a field
curl -X POST -H "Content-type: application/json" --data @addfields.json
http://localhost:8983/solr/collectionname/schema
curl http://localhost:8983/solr/collectionname/schema/fields
vim deletefields.json # Add the fields just added here
- If I need to do it again, I have two options:
(A) upconfig the configuration and reload the core, this removes the
added fields
(B) Run deletefields.json via POST before repeating Add my fields
- When the schema is complete (or periodically), you can downconfig it:
zkcli.sh -z localhost:9983 -cmd downconfig -confdir conf -confname
configname
git add conf
git commit
- This was simplified because I simply didn't successfully index until I'd
defined all the needed fields and I'm not worrying about elevation, synonyms,
etc. much yet.
-----Original Message-----
From: Alexandre Rafalovitch [mailto:[email protected]]
Sent: Wednesday, March 16, 2016 3:15 AM
To: solr-user <[email protected]>
Subject: Making managed schema unmutable correctly?
So, I am looking at the Solr 5.5 examples with their all-in by-default managed
schemas. And I am scratching my head on the workflow users are expected to
follow.
One example is straight from documentation:
"With the above configuration, you can use the Schema API to modify the schema
as much as you want, and then later change the value of mutable to false if you
wish to "lock" the schema in place and prevent future changes."
Which sounds great, except right above the definition in the solrconfig.xml, it
says:
"Do NOT hand edit the managed schema - external modifications will be ignored
and overwritten as a result of schema modification REST API calls."
And the Config API does not seem to provide any API to switch that property
(schemaFactory.mutable is not an editable property).
So, how is one supposed to lock the schema after modifying it? In the default,
non-cloud, example!
So far, the nearest I get is to unload the core (losing core.properties),
manually modify solrconfig.xml in violation of instructions and add the core
back. What am I missing?
Regards,
Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/
