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 > > 1. maxShardsPerNode > 2. rule > 3. snitch > 4. policy > 5. collection.configName > 6. autoAddReplicas > 7. 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 ? > > >
