Elastic allows the mappings to be set all at once, either in the template or as index settings. That is an important feature because it allows the field definitions to be source code artifacts, which can be deployed very easily by an automatic script.
Solr's Managed Schema API allows multiple changes to be combined into a single POST, but the API changes are not declarative - they modify the current schema rather than setting it. It would be better if there were an API in the managed schema API to declaratively set the schema field defs, fields, dynamic fields, and copy fields through a single API call. This would replace the current function of schema.xml Since that mechanism does not yet exist, I think it is too soon to eliminate schema.xml. This function of setting it declaratively to exactly what you want is also met by using an uploaded configset, and since solrconfig.xml isn't going away, then this step is not eliminated, and so it seems that an additional step to reliable deployment is introduced. That said, as long as there is a strong idea of the baseline schema, achieving the desired schema via add, remove, and replace operations is reasonable. > -----Original Message----- > From: Doug Turnbull [mailto:dturnb...@opensourceconnections.com] > Sent: Tuesday, June 19, 2018 12:06 PM > To: solr-user@lucene.apache.org > Subject: Re: Remove schema.xml in favor of managed-schema > > 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
