I think each individual change mostly made sense. What I think becomes a problem is expecting the user to understand the end result when they are not aware of what different things have and where they live.
solrconfig.xml is a very large beast already. But, until recently, there was a sense that one could read and/or grep for whatever one did not understand (request handler name, parameter name, etc) in one of those two files (solrconfig.xml, schema.xml) and have the answer. Now, we have 3 files and two API calls for solrconfig.xml, two names for schema (yes, schema.xml given all _other_ tutorials on the web) and whatever the magic _rest_managed.json file is for meta-managing managed components. Plus, the implicit handlers, and now implicit initParam names for implicit handlers :-) And, still dark magic to me, the order of invocation between parameter information passed through the request handler, initParams, params.json, request params directly, request params mentioning params groups, etc (ok, I am rambling here). I think magic is not bad (that's a recent change of mind frankly), if that significantly simplifies workflow and still allows for easy debugging. But I am not sure the current state - taken all together - achieves either of two purposes. I think looking at all these different thinks together, understanding the use cases and perhaps slimming down to a unified forward-back path would be best. So, a single format (JSON if it works, JSON+comments/quotes that Solr actually supports, or whatever). But then the inputs and outputs should be consistent so that the same tooling could be used for everything. Too much to dream about? Regards, Alex. P.s. Oh, and minimum solrconfig.xml requires luceneMatchVersion to be present. And possibly a /select handler. But yes, a valid core configuration can be very very small. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 26 September 2016 at 14:10, Noble Paul <noble.p...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
