Erick Erickson created SOLR-9583:
------------------------------------

             Summary: When the same <uniqueKey> exists across multiple 
collections that are searched with an alias, the document returned in the 
results list is indeterminant
                 Key: SOLR-9583
                 URL: https://issues.apache.org/jira/browse/SOLR-9583
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Erick Erickson


Not quite sure whether to call this a bug or improvement...

Currently if I have two collections C1 and C2 and an alias that points to both 
_and_ I have a document in both collections with the _same_ <unkqueKey>, the 
returned list  sometimes has the doc from C1 and sometimes from C2.

If I add shards.info=true I see the document found in each collection, but only 
one in the document list. Which one changes if I re-submit the identical query.

This seems incorrect, perhaps a side effect of piggy-backing the collection 
aliasing on searching multiple shards? (Thanks Shalin for that bit of 
background).

I can see both use-cases: 

1>  aliasing multiple collections validly assumes that <uniqueKey>s should be 
unique across them all and only one doc should be returned. Even in this case 
which doc should be returned should be deterministic.

2> these are arbitrary collections without any a-priori relationship and 
identical <unkqueKey>s do NOT identify the "same" document so both should be 
returned.

So I propose we do two things:

a> provide a param for the CREATEALIAS command that controls whether docs with 
the same <unkqueKey> from different collections should both be returned. If 
they both should, there's still the question of in what order.

b> provide a deterministic way dups from different collections are resolved. 
What that algorithm is I'm not quite sure. The order the collections were 
specified in the CREATEALIAS command? Some field in the documents? Other??? 
What happens if this option is not specified on the CREATEALIAS command?

Implicit in the above is my assumption that it's perfectly valid to have 
different aliases in the same cluster behave differently if specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to