How about adding a deleteConfig() which fails if there are existing collections that still refer it? I think it's something we'd want to avoid even if there are no collections which are currently being created, but also ones that already exist. E.g. if they reload a core or something, they won't find the config.
We can also offer it at first as at-your-own-risk, maybe only on ZkConfManager (i.e. I consider CloudSolrClient the 'official' API) as a helper at your own risk. I agree about listConfigs(), I'll open an issue. Shai On Mon, Apr 20, 2015 at 7:06 PM, Alan Woodward <[email protected]> wrote: > Shawn and I talked about adding that, but it's complicated, because you > don't want to delete a config when another collection is in the middle of > being created with it. > > Would be nice to add listConfigs() directly to CloudSolrClient as well. > > Alan Woodward > www.flax.co.uk > > > On 20 Apr 2015, at 16:44, Shai Erera wrote: > > Hi > > In 5.1 CloudSolrClient offers uploadConfig, downloadConfig, listConfigs, > but no deleteConfig. Is that because it's covered by another class, or > there is an issue to support it? > > I don't mind adding one, just wanted to check it wasn't added because it > can't be supported now. > > Shai > > >
