[
https://issues.apache.org/jira/browse/SOLR-17570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900460#comment-17900460
]
Chris M. Hostetter commented on SOLR-17570:
-------------------------------------------
{quote}Unfortunately I think we have no way to completely disable numFound. if
minExactCount is 0, this is our only way to basically convey that in a
round-about way; do you agree?
{quote}
Agree? ... but your wording has me suspicious that it's a trick question,
because it doesn't even seem that roundabout -- isn't that the exact purpose of
being able to set {{minExactCount=0}} ?
But again: I'm not very familiar with the {{minExactCount}} feature...
>From what you're saying though it sounds like we still always return a
>{{numFound}} no matter what – it's just that that {{numFound}} is no longer
>exact ... which thinking about it more makes me more concerned about the
>backcompat situation (if there is someone out there using {{cursorMark}} that
>*does* care about {{numFound}} i really don't like the idea that on upgrading
>to some future version of Solr their {{numFound}} is now silently "wrong"
>because we changed the default of {{minExactCount}} when using
>{{{}cursorMark{}}}.
Which brings me back to...
{quote}(Although to be really good about backcompat in the same way we have in
the past for changing defaults like this: the default value of
{{minExactCount}} should be based on _both_ {{cursorMark}} being non-null and
luceneMatchVersion < XXX – where XXX is whatever value is in the defualt
configset in the version of solr where you make this change)
{quote}
> cursorMark should assume minExactCount=0
> ----------------------------------------
>
> Key: SOLR-17570
> URL: https://issues.apache.org/jira/browse/SOLR-17570
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
>
> Claim: Someone using cursorMark (deep paging) probably doesn't care about
> numFound at all, and thus could set minExactCount=0 param. And if they want
> to know, they either find out on the first page straight away (nextCursorMark
> is absent) or failing that, it could send a query purely to ascertain what
> numFound is if it doesn't want to page to the end.
> I see no test with both functionalities together. I think it should work
> this way by default. I tried this with a quick hack using
> DistribCursorPagingTest and it triggered an assertion in
> {{org.apache.solr.search.SolrIndexSearcher#sortDocSet}} that didn't need to
> be there -- it can be removed. The functionality worked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
