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

Reply via email to