[
https://issues.apache.org/jira/browse/SOLR-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter resolved SOLR-6981.
----------------------------------
Resolution: Fixed
Fix Version/s: Trunk
> 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, Trunk
>
>
> 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]
