"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
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
i
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 con
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 c
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, 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.
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 f
I think my query got misinterpreted.
I only wanted to know if schema.xml offer anything that managed-schema does
not.
Best,
SG
On Sat, Jun 16, 2018 at 6:45 PM Erick Erickson
wrote:
> Currently, there are no restrictions on hand-editing config files,
> mutable or not.
>
> The rub is that any o
Currently, there are no restrictions on hand-editing config files,
mutable or not.
The rub is that any of the APIs that modify configs operate on their
in-memory copy and write that out (both Cloud and stand-alone modes).
So if I start Solr, the nodes have image of the configs at time T.
Now I ha
I'm not sure changing something from mutable -> unmutable means it suddenly
becomes hand-editable.
I don't know the details here, but I can imagine a case that unmutable
implies some level of consistency, where the file is hashed, and later
might be confirmed to still be the same 'unmutable' state
