As a Solr user, my feeling is that the proposal would be a significant improvement in the product design. A significant piece of related work, imo, would be to update all of the examples and "getting started" docs. Likewise, isn't the plan for migration from 4.x to 5.x (wrt to maintenance, monitoring, ETL, etc.) is affected by this issue? I feel clarity and stability in these areas would help adoption of 5.x.
Re: SOLR-6278, My feeling is that the term "core" could just go away with the public API . There should be a single, clear cut way to address individual replicas, of any given shard, within any collection. Even if there is only one replica (the leader) and only one shard, the addressing scheme and terminology remain the same. If there are functional gaps in the Collections API, fill them as needed - perhaps by delegating to the internal "Admin" service at the node level. But please keep the public parameters and terminology consistent. There should be only one way to do it ... On Saturday, March 28, 2015 9:17 PM, Yonik Seeley [mailto:[email protected]] wrote: > > On Sat, Mar 28, 2015 at 2:27 PM, Erick Erickson <[email protected]> > wrote: > > Fold any functionality we still want > > to support at a user level into the collections API. I mean a core on > > a machine is really just a single-node collection sans Zookeeper, > > right? > > +1, this is the position I've advocated in the past as well. > > -Yonik On Sunday, March 29, 2015 7:53 PM, Ramkumar R. Aiyengar [mailto:[email protected]] wrote: > > Sounds good to me, except that we have to reconcile some of the objections in > the past > to collection API additions, like with > https://issues.apache.org/jira/SOLR-6278. In short, > collection API provides you a way to operate on collections. Operationally > you would often > also want functionality based off physical location (e.g. I need to > decommission this machine, > so boot and delete everything on it), core admin appeared to be the place for > it. ************************************************************************* This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and then delete it. TIAA-CREF *************************************************************************
