Manage schema

[Firesphere]

There's currently no process in place to manage the schema, even though it's a wished feature

[chillu]

You mean http://lucene.apache.org/solr/guide/8_1/schema-api.html#schema-api? Yeah, that'd be grand, because every install needs to customise the schema, and only some installs need to customise solrconfig.xml.

From my understanding, FTS currently generates schema.xml on Solr_Configure, and then uploads it via a custom CWP proxy script (not WebDAV, not anything built into Solr). Assuming that our most common use case will be running Solr on a remote box, we can't run mode=file because that's not actually allowing you to copy changed XML files from a webserver to the Solr server.

There's no API to modify solrconfig.xml, you need to have that file available on the Solr server at the time when the core is created. Core creation can happen remotely via API, referencing a local file on the Solr server for configuration. See http://lucene.apache.org/solr/guide/8_1/coreadmin-api.html#coreadmin-api

[Firesphere]

Yes, managed schema indeed, as per your link, is what I'm looking at.
This would potentially even remove the need for a schema.xml to be generated in the first place, giving the option to have an initial configuration from yml and then use the CMS controls in place (to be done, ™️ ) to further control the schema.

I am aware of not being able to use the file mode for remote servers, which is why I'm looking in to post and webdav stores (I'm still not fully gotten my head around the CWP implementation, black box magic, as I have other priorities).

SolrConfig.xml should be modifiable as far as I can see, but (and that's the big one), it needs to exist before a core can be loaded, and Solr does not provide an endpoint for this.

A possible solution is again a custom proxy for loading this. I would not do this through apache and php though, but with a broader Python or Ruby script, that gives more granular control than just writing it to a file.

You are not the first to be annoyed by this lack of support from Solr to instantiate a core on the fly, that's for sure! :D

[marczhermo]

I delved into coreadmin api last April and is looking forward to incorporate the code I've done here.
Also I suggest we look into zookeeper approach as an alternative to proxy black box.

[Firesphere]

I've scheduled this change for the next major release. I prefer the module to be stable and working with the current situation, before introducing new variables that could distract from the core functionality.