Thanks for saying. I thought as soon as I sent it that my motivation might just be to brag that I know something that long-time Solr folks like you might not. I actually know so very little, not just about how Lucene works, but how to make Solr solve concrete problems beyond the simple. I feel like just now am I really upping my game; hopefully it continues.
-----Original Message----- From: Alexandre Rafalovitch [mailto:arafa...@gmail.com] Sent: Wednesday, March 16, 2016 5:44 PM To: solr-user <solr-user@lucene.apache.org> Subject: Re: Making managed schema unmutable correctly? Daniel, Thank you for the very concrete example. That is helpful. Regards, Alex. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 17 March 2016 at 08:17, Davis, Daniel (NIH/NLM) [C] <daniel.da...@nih.gov> wrote: > 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:arafa...@gmail.com] > Sent: Wednesday, March 16, 2016 3:15 AM > To: solr-user <solr-user@lucene.apache.org> > 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/
