[
https://issues.apache.org/jira/browse/SOLR-6121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073471#comment-14073471
]
Hoss Man commented on SOLR-6121:
--------------------------------
bq. or the chances of their being duplicates is so low that I am happy for that
odd search to skip a result instead of every search incurring the overhead
it's not just a question of missing an occasional doc -- w/o a definitive tie
breaker included in the cursorMark, you'll get an infinite loop any time the
the number of docs with identical sort values is greater then the size of the
rows param. Definitely not a trap we want to leave in for users who just don't
think to include "id" in the sort
bq. May be my sort key is unique as well even if not the schema's unique key,
... have an optional param which explicitly tells you that this is fine?
that seems like a good idea, but is really orthogonal to the spirit of this
jira which is about simplifying the user experience and magically adding the
uniqueKey tiebreaker behind the scenes.
for expert users who know their sort is already unique, and want to add a new
param that tells the cursor code "skip the overhead of uniqueKey tiebreaker, my
last clause is guaranteed to be a tiebraker" seems fine -- please open a new
jira.
> cursorMark should accept sort without the uniqueKey
> ---------------------------------------------------
>
> Key: SOLR-6121
> URL: https://issues.apache.org/jira/browse/SOLR-6121
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Minor
>
> If you are using the cursorMark (deep paging) feature, you shouldn't *have*
> to add the uniqueKey to the sort parameter. If the user doesn't do it, the
> user obviously doesn't care about the uniqueKey order relative to whatever
> other sort parameters they may or may not have provided. So if sort doesn't
> have it, then Solr should simply tack it on at the end instead of providing
> an error and potentially confusing the user. This would be more user
> friendly.
> Quoting Hoss from
> [SOLR-5463|https://issues.apache.org/jira/browse/SOLR-5463?focusedCommentId=14011384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14011384]:
> {quote}
> The reason the code currently throws an error was because i figured it was
> better to force the user to choose which tie breaker they wanted (asc vs
> desc) then to just magically pick one arbitrarily.
> If folks think a magic default is a better i've got no serious objections –
> just open a new issue.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
