lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Potter (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (SOLR-6981) bin/solr should have a delete action to complement the create action
Date Fri, 16 Jan 2015 06:41:34 GMT

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message