Closed mpeeters closed 2 years ago
@mpeeters just wondering: why don't you just use a virtual Solr core and handle this on Solr itself to keep things transparent for Plone?
@mpeeters jikes. I think I screwed up your PR with my latest changes in the main branch. Sorry for that. Can you look into rebasing?
@tisto the usecase is to allow search accross multiple SolR core that contains differents sets of data and may have different schemas because they are used by other Plone instances. This is the reason why this is limited to search.
@mpeeters I totally get the use case, because that's a common use case that we have as well. The thing I don't fully get is why you don't solve this with an individual "virtual" solr core that is used by a Plone instance. This way you don't need to add anything to collective.solr. The only possible downside of this Solr-only approach is that you need a (virtual) Solr core for each Plone instance you have.
@mpeeters somehow GHA are not triggered for this PR. Can you re-base to trigger a build?
@tisto I see your point, the problem here is that the client have more than 100 Plone websites that will search in only 3 shared Plone instances, duplicating core would involve huge infrastructure maintenance issues due to the large number of core to maintain. This is the main reason of this PR.
@mpeeters got it. I just wanted to understand your use case. Makes sense. Let's get GHA green on this PR and I can review, merge and release.
@tisto it seems that GHA does not run for PR where branches are from fork.
But you can check the status here : https://github.com/IMIO/collective.solr/actions?query=branch%3Amulticore++
@tisto I've rebased the pull request. Could you please review & merge it before #319 ?
Thank you :pray:
Thanks @tisto
This PR add a new parameter
core
for SolR search that can be used to search on other SolR core from the same SoLR server.To allow a search from a new SolR core, a new named utility must be defined for ISolrConnectionManager with the core id as name.