[jira] [Created] (SOLR-6981) bin/solr should have a delete action to complement the create action

["Timothy Potter (JIRA)" <ji...@apache.org>]

Timothy Potter created SOLR-6981:
------------------------------------

             Summary: bin/solr should have a delete action to complement the create action
                 Key: SOLR-6981
                 URL: https://issues.apache.org/jira/browse/SOLR-6981
             Project: Solr
          Issue Type: New Feature
          Components: scripts and tools
            Reporter: Timothy Potter
            Assignee: Timothy Potter
            Priority: Critical
             Fix For: 5.0


In SOLR-6952, we changed the create_collection logic to create a copy of a configset in ZooKeeper by default, i.e. if you do {{bin/solr create -c foo}} then then the {{server/solr/configsets/data_driven_schema_configs}} directory is uploaded to ZK as {{/configs/foo}} ... Since it is data driven, the managed schema starts to change as docs flow in ... good so far ... now the user decides to delete the foo collection and re-create it. The delete collection action leaves the /configs/foo directory in ZK and the create action in bin/solr does not overwrite existing files in ZooKeeper. So something very subtle happens, the previous data-driven changes are still in effect, which will be quite confusing for new users who think the delete action removed the configs.

For now, I think the bin/solr script should handle this on the delete side by:

1) checking to make sure the config is not being used by any other collection
2) delete the /configs/foo after deleting the collection

If the check for #1 fails, then the delete will proceed with a simple WARNING that the configs are shared and will not be deleted by this action.

Looking ahead, we probably want to deal with this copying of configsets and then handling the deletes correctly in the collections API, i.e. right now, the smarts can live in the bin/solr script and SolrCLI but the long-term solution should be to move those smarts into the CREATE and DELETE actions of the Collections API. We also should think about making the concept of a "shared" configuration directory more explicit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org