I strongly prefer the classic config files approach. Our config files are 
checked into
version control. We update on the fly by uploading new files to Zookeeper, then 
reloading the collection. No restart needed.

Pushing changes to prod is straightforward. Check out the tested files, load 
them
into the prod cluster, reload the collection. 

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 19, 2018, at 9:06 AM, Doug Turnbull 
> <dturnb...@opensourceconnections.com> wrote:
> 
> I actually prefer the classic config-files approach over managed schemas.
> Having done both Elasticsearch (where everything is configed through an
> API), managed and non-managed Solr, I prefer the legacy non-managed Solr
> way of doing things when its possible
> 
> - With 'managed' approaches, the config code often turns into spaghetti
> throughout the client application, and harder to maintain
> - The client application is often done in any number of programming
> languages, client APIs, etc which makes it harder to ramp up new Solr devs
> on how the search engine works
> - The file-based config can be versioned and deployed as an artifact that
> only contains config bits relevant to the search engine
> 
> I know there's a lot of 'it depends'. For example, if I am programatically
> changing config in real-time without wanting to restart the search engine,
> then I can see the benefit to the managed config. Especially a large,
> complex deployment. But most Solr instances I see are not in the giant,
> complex to config variety and the config file approach is simplest for most
> teams.
> 
> At least that's my 2 cents :)
> -Doug
> 
> 
> On Tue, Jun 19, 2018 at 11:58 AM Alexandre Rafalovitch <arafa...@gmail.com>
> wrote:
> 
>> And that managed-schema will reorder the entries and delete the comments on
>> first API modification.
>> 
>> Regards,
>>    Alex
>> 
>> On Tue, Jun 19, 2018, 11:47 AM Shawn Heisey, <apa...@elyograg.org> wrote:
>> 
>>> On 6/17/2018 6:48 PM, S G wrote:
>>>> I only wanted to know if schema.xml offer anything that managed-schema
>>> does
>>>> not.
>>> 
>>> The only difference between the two is that there is a different
>>> filename and the managed version can be modified by API calls.  The
>>> schema format and what you can do within that format is identical either
>>> way.
>>> 
>>> Thanks,
>>> Shawn
>>> 
>>> 
>> 
> -- 
> CTO, OpenSource Connections
> Author, Relevant Search
> http://o19s.com/doug

Reply via email to