I agree that configuring Solr through the APIs is a better option than uploading huge XMLs, but we should strive for copy/paste-ability wherever possible. Ideally it should be possible to store your config/schema information in JSON format in GIT and easily POST it after creating a new collection. The exact same JSON should also be possible to paste into the Admin UI in order to reproduce the same config/schema. And if you do a GET request to fetch config/schema, the resulting JSON should ideally be in a format that can be again checked into GIT and work when re-creating the same collection.
Am I right that the bulk API style of embedding the verb into the data object itself, e.g. "add-field-type”, is the main source of the difference here, or is it more complex than that? Looks to me that the JSON object after “add-field-type” and “replace-field-type” is exactly the same as the one you get from a call to GET /solr/collection/schema/fieldtypes/name?omitHeader=true except from the latter being wrapped in a “fieldType” object. I’m not totally against the “add-field-type” bulk style API, but perhaps we should also have a GET/POST /solr/collection/schema endpoint which supports roundtrip of the whole schema in JSON format? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 26. sep. 2016 kl. 09.10 skrev Noble Paul <noble.p...@gmail.com>: > > 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 >
