So let's keep *collection.configName* and *replicationFactor*. If we were to think of this API today , would MODIFYCOLLECTION be where we still put it?
It almost feels like a collection setting. Maybe Collection Properties ( SOLR-11960 ) is where it should live? On Fri, Jun 15, 2018 at 4:58 PM, Erick Erickson <[email protected]> wrote: > re: collection.configName > > bq. Right and then basically we are giving a way for users to shoot > themselves in the foot :) > > They can also delete their index files.... > > Seriously though, what if I have a bunch of collections sharing a > configset then I need to specialize only one by _adding_ fields? I'd > like to copy the configset to a new one and then point my collection > at it. And with the UninvertingMergePolicy adding DV would be one such > specialization. > > I've also seen time-series collections (let's say 30 days) where you > _cannot_ reindex. But you want to modify your schema anyway. People > have > 1> defined a new field that's a variant of the old field > 2> have their indexing program index to _both_ for 30 days > 3> change the app to use the new field > 4> change the indexing program to stop indexing to the old field > > Sure, the metadata for the field is still carried along but that's not > a problem for a few fields. > > Point is it's dangerous to go changing your configset for an existing > collection, sure. But I find the API a better option than having to > manually edit your ZK nodes. > > FWIW > > On Fri, Jun 15, 2018 at 7:18 AM, Varun Thacker <[email protected]> wrote: > > Hi Jan, > > > > I agree with how your thinking of replicationFactor as basically being a > > equivalent to nrtReplicas . Let's not change that. > > > > so the is #7 the real only use for this API? > > > > On Fri, Jun 15, 2018 at 1:46 PM, Jan Høydahl <[email protected]> > wrote: > >> > >> Do we have a v2 API for CREATE and MODIFYCOLLECTION? E.g. > >> > >> POST http://localhost:8983/api/c > >> { modify-collection: { replicationFactor: 3 } } > >> > >> Perhaps we should focus on a decent v2 API and deprecate the old > confusing > >> one? > >> > >> wrt. replicationFactor / nrtReplica / pullReplicas / tlogReplicas, my > wish > >> is that replicationFactor keeps on living as today, only setting > >> nrtReplicas, and is mutually exclusive to any of the three others. So > if you > >> have a collection with tlogReplicas defined, then modifying > >> "replicationFactor" should throw and error. But if you only ever care > about > >> NRT replicas then you can keep using replicationFactor as before??? > >> > >> -- > >> Jan Høydahl, search solution architect > >> Cominvent AS - www.cominvent.com > >> > >> 15. jun. 2018 kl. 13:22 skrev Varun Thacker <[email protected]>: > >> > >> Today the Modify Collection supports the following properties to be > >> modified > >> > >> maxShardsPerNode > >> rule > >> snitch > >> policy > >> collection.configName > >> autoAddReplicas > >> replicationFactor > >> > >> 1-4 seems something we should get rid of because we have the AutoScaling > >> Policy framework? > >> > >> 5> Can anyone point out the use-case for this? > >> > >> 6> autoAddReplicas can be changed as a clusterprop and modify-collection > >> API ? Hmm. Which one is supposed to win? > >> > >> 7> We need to allow a user to change replicationFactor. But how does > this > >> help? We have nrtReplicas / pullReplicas / tlogReplicas so changing this > >> sounds just confusing? Or allow changing all replica types ? > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
