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]
