I would second that guide could be clearer on that. I read and reread several times trying to get my head around the schema.xml/managed-schema bit. I came away from first cursory reading with the idea that managed-schema was mostly for schema-less mode and only after some stuff ups and puzzling over comments in the basic-config schema file itself did I go back for more careful re-read. I am still not sure that I have got all the nuances. My understanding is:
If you don’t want ability to edit it via admin UI or config api, rename to schema.xml. Unclear whether you have to make changes to other configs to do this. Also unclear to me whether there was any upside at all to using schema.xml? Why degrade functionality? Does the capacity for schema.xml only exist for backward compatibility? If you want to run schema-less, you have to use managed-schema????? (I didn’t delve too deep into this). In the end, I used basic-config to create core and then hacked managed-schema from there. I would have to say the "basic-config" seems distinctly more than basic. It is still a huge file. I thought perhaps I could delete every unused field type, but worried there were some "system" dependencies. Ie if you want *target type wildcard queries do you need to have text_general_reverse and a copy to it? If you always explicitly set only defined fields in a custom indexer, then can you dump the whole dynamic fields bit? Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents.
