You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Damien Kamerman (JIRA)" <ji...@apache.org> on 2016/11/29 23:56:59 UTC
[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded
collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15706971#comment-15706971 ]
Damien Kamerman commented on SOLR-8297:
---------------------------------------
The use case is not narrow in my view. I have a sharded collection holding multiple data-sets that I wish to join on. I'm joining on the same collection.
Will this patch be applied to 6.x?
> Allow join query over 2 sharded collections: enhance functionality and exception handling
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 5.3
> Reporter: Paul Blanchaert
> Attachments: SOLR-8297.patch
>
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in the function findLocalReplicaForFromIndex of JoinQParserPlugin is not triggered correctly: In my use-case, I've a join on a facet.query and when my results are only found in 1 shard and the facet.query with the join is querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the "multiple shards not yet supported" exception (so exception is thrown when zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection of "fromindex" has router.field = "from" field and collection joined to has router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are routed to the same node.
> So the combination based on the "key-field" should always be available within the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" use-case in the cross-core join in SolrCloud.
> Hope this helps
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org