sigram edited a comment on pull request #1813: URL: https://github.com/apache/lucene-solr/pull/1813#issuecomment-686410621
> Honestly nobody will do that. People would rather happily do the computation in client code Really? This is like saying that we only ever need collection admin APIs and we don't need any autoscaling. That may be the case for some people, but not for others. Also, not everybody would go and implement their own plugin, instead they would likely use someone else's plugin that is known to work for a particular scenario. I think the opposite of what you said is true - the expectation is that Solr will behave in a sane way and automatically do what's needed to "properly" use available resources, without too much manual handholding. The problem is of course that the definition of "properly" depends on the point of view and the scale of the problem - that's why we're having the discussion about plugins at all. Take Salesforce's case for example: they had to hack around the existing AssignStrategy to implement their own, because the default ones didn't work for them. In the process they had to learn and mess around with a lot of Solr internals. It would have been clearly better if they could just implement it as an installable plugin, using an abstract API that doesn't expose too many Solr internals. Edit: oh, and obviously one of the valid strategies would be to rely on provided placements (basically a do-nothing-strategy), but having this option as a plugin with a clean API is clearly better than just a bunch of messy hardcoded conditionals. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
