Description
bin/solr advises default config users to turn off data driven schema functionality, e.g.:
PROMPT$ bin/solr start -c [...] Waiting up to 180 seconds to see Solr running on port 8983 [-] Started Solr server on port 8983 (pid=74200). Happy searching! PROMPT$ bin/solr create -c mycoll WARNING: Using _default configset with data driven schema functionality. NOT RECOMMENDED for production use. To turn off: bin/solr config -c mycoll -p 8983 -property update.autoCreateFields -value false
When I try the above command, it claims to succeed, but in fact silently fails - see below (I'll open a separate JIRA for the false success problem).
When I attempt to set this property via the equivalent direct call to the Config API, it fails:
PROMPT$ curl -X POST http://localhost:8983/solr/mycoll/config -d '{set-property: { update.autoCreateFields: false }}' { "responseHeader":{ "status":0, "QTime":8}, "errorMessages":[{ "set-property":{"update.autoCreateFields":false}, "errorMessages":["'update.autoCreateFields' is not an editable property"]}], "WARNING":"This response format is experimental. It is likely to change in the future."}
The correct action to use here is set-user-property rather than set-property. SOLR-11108 changed the bin/solr output from the correct Config API command to an incorrect bin/solr config command.
bin/solr should instead be printing (note the -action param):
To turn off: bin/solr config -c mycoll -action set-user-property -p [...] -property update.autoCreateFields -value false
Attachments
Attachments
Issue Links
- is broken by
-
SOLR-11108 Shorten _default configset warning and use ConfigTool
- Closed
- relates to
-
SOLR-12482 Config API returns status 0 for failed operations
- Closed