lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Khludnev (JIRA)" <>
Subject [jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
Date Thu, 28 Apr 2016 10:12:13 GMT


Mikhail Khludnev commented on SOLR-8297:

I tried but it seems like only commetters can be assignee. However, patch is quite welcome!!!

> Allow join query over 2 sharded collections: enhance functionality and exception handling
> -----------------------------------------------------------------------------------------
>                 Key: SOLR-8297
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>    Affects Versions: 5.3
>            Reporter: Paul Blanchaert
> 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
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message