: > 2) If you wish to use the /schema REST API for read and write operations, : > then schema information will be persisted under the covers in a data store : > whose format is an implementation detail just like the index file format. : : This really needs to be driven by costs and benefits... : There are clear benefits to having a simple human readable / editable : file for the schema (whether it's on the local filesystem or on ZK).
The cost is the user complexity of understanding what changes are respected and when, and in hte implementation complexity of dealing with changes coming from multiple code paths (both files changed on disk and REST based request changes) in the current model, the config file on disk is hte authority, it is read in it's entirety on core init/reload, and users have total ownership of that file -- changes are funneled through the user, into the config, and solr is a read only participant. Since solr knows the only way schema information will ever change is when it reads that file, it can make internal assumptions about the consistency of that data. in a model where a public REST API might be modifying solr's in memory state, solr can't neccessarily make those same assumptions, and the complexity of the system becomes a lot simpler if the Solr is the "authority" of the information about the schema, and we don't have to worry about what happens if comflicts arrise, eg: someone modifies the schema on disk, but hasn't (yet?) done a core reload, when a new REST request comes in to modify the schema data in some other way. -Hoss
