Well, if using managed schema in SolrCloud, all the updates to the nodes is automatic so it's easier from that perspective.
To me, the sweet spot for managed schema is that it lends itself to some kind of front end that allows you to deal with the schema visually, one can envision widgets, pick-lists and in general all the stuff that goes with a comprehensive UI. Managed also has the advantage of making it much harder to create mal-formed XML which has always been a possibility with hand editing. Personally I prefer to hand-edit the files. One can even combine the two, hand edit the managed-schema file before, say, putting it up on Zookeeper then use the managed portion thereafter. There's no real reason you can't hand-edit the schema. But as Shawn mentioned, you must do this when there are no solr instances looking at it or you risk losing your edits. Really, it's a matter of taste/tooling. Best, Erick On Wed, Mar 16, 2016 at 6:51 PM, Jay Potharaju <jspothar...@gmail.com> wrote: > Does using schema API mean that no upconfig to zookeeper and no reloading > of all the nodes in my solrcloud? In which scenario should I not use schema > API, if any? > Thanks > Jay > > On Wed, Mar 16, 2016 at 6:22 PM, Shawn Heisey <apa...@elyograg.org> wrote: > >> On 3/16/2016 1:14 AM, Alexandre Rafalovitch wrote: >> > 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? >> >> Note that you *can* hand edit the managed-schema file. It's *strongly* >> not recommended if you actually plan to use the Schema API, because any >> changes you make manually will be lost if you subsequently use the >> Schema API before restart/reload ... but if you always hand edit the >> file, or you are *very* careful to make sure that the core/collection >> has been reloaded before using the Schema API, then that won't matter. >> This is difficult to explain in a concise config comment though, so >> hand-editing is simply discouraged. >> >> Thanks, >> Shawn >> >> > > > -- > Thanks > Jay Potharaju
