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: [email protected]
For additional commands, e-mail: [email protected]
