lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Potter (JIRA)" <>
Subject [jira] [Created] (SOLR-6981) bin/solr should have a delete action to complement the create action
Date Wed, 14 Jan 2015 21:07:35 GMT
Timothy Potter created SOLR-6981:

             Summary: bin/solr should have a delete action to complement the create action
                 Key: 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message