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
