As the main culprit here let me put forward my few cents * The intent is to go away from config files. Users should use APIs to read and edit configurations. Editing configuration is both error prone and old school * I prefer to store everything is JSON. json is modern and simple. * Even today it is totally possible to put an empty solrconfig.xml and move everything to configoverlay.json. We may not need to wait for a big release to do that * schema is still in xml . there is significant effort involved in changing it over * There is a reason why the /config output has solrconfig.xml and overlay.json merged because they don't make sense individually. params are not relevant unless there is a reference to it in the config. If a requesthandler refers to a paramset, we probably should show it inline * Yes , you can't round-trip the output of config. I thought of adding a wt which emits a "round-trippable" JSON (like the SHOW CREATE TABLE functionality in RDBMS)
On Mon, Sep 26, 2016 at 5:35 AM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > Did you know about configoverlay.json? > > +1 to the discussion. > > Additional fuel to the fire is that /config endpoint will return > solrconfig.xml + overlay.json merged, but not params.json. Confusing. > > Additionally, /config output is JSON but not one that can round-trip AFAIK. > > Regards, > Alex > > > On 26 Sep 2016 12:42 AM, "Shawn Heisey" <apa...@elyograg.org> wrote: >> >> There seems to be some fracturing in the format of various Solr >> configs. Most of the config uses XML, but some new features in the last >> few years are using JSON, particularly where SolrCloud and Zookeeper are >> concerned. When notifications about SOLR-9557 came through, it revealed >> that there is a config file sitting next to solrconfig.xml named >> "params.json" that Solr will use. I wasn't aware of this until reading >> that issue. >> >> This leads me to suggest something rather drastic for 7.0: Consolidate >> all configuration formats and agree to consistent format usage unless >> there is another major discussion and agreement to change formats. >> >> I did consider starting this discussion in Jira, but it's fairly major, >> so the dev list seemed like the right place to start. >> >> Comments from some new users have come my way along the lines of "XML is >> so 90's ... get with the times!" Image problems like that can be fatal >> to a software project, even if there's no technical problem. >> >> The likely winner in the format discussion is pure unmodified JSON, but >> I'm not going to make any assumptions. SOLR-8029 has some format >> discussions that may be relevant here. >> >> IMHO, in order to make the idea successful, Solr 7.0 will need to >> automatically convert most configs on startup from the old format to the >> new format without user intervention. If there's something that we find >> we can't convert automatically, that should result in a failure to >> start, with a helpful message so the user has some idea what they need >> to do. >> >> Thoughts? Is this too scary to contemplate? Should I open an umbrella >> issue in Jira to get the ball rolling? >> >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
