lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S G <sg.online.em...@gmail.com>
Subject Re: Remove schema.xml in favor of managed-schema
Date Fri, 22 Jun 2018 18:07:01 GMT
"And that managed-schema will reorder the entries and delete the comments
on first API modification." - This is something very irritating when
comparing files with the default version of Solr to see what has changed.
When upgrading schemas/configs for new version of Solr, such automatically
removed comments are a giant pain to work with.
This does not mean that managed-schema is less useful but Solr should try
to preserve the comments and formatting etc when adding content through
schema APIs



On Wed, Jun 20, 2018 at 4:35 PM Walter Underwood <wunder@wunderwood.org>
wrote:

> 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
> wunder@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On Jun 19, 2018, at 9:06 AM, Doug Turnbull <
> dturnbull@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 <
> arafalov@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, <apache@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message