[
https://issues.apache.org/jira/browse/SOLR-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923312#comment-15923312
]
Hoss Man commented on SOLR-10231:
---------------------------------
bq. Btw, would the same issue exist in 6.x?
yeah, there's nothing version specific happening here -- it's just the nature
of the way cursors work. Sorting by a NOW relative function like this, where
the result for each doc changes every time you send a request, is just like
sorting on a field that you constantly update for every doc in between every
request.
bq. (Perhaps the NOW value should also be encoded into the cursor values so
this happens automatically under the covers? ... not sure if that's a good idea
in general, would need to think about it more)
The more i think about it, the more convinced i am this wouldn't be a good idea
-- because it would complicate usescases where people want filter queries that
involve "NOW" that they *do* want/expect to change in subsequent requests as
they walk cursor -- ie: an {{fq=expiresAt:\[\NOW TO *\]}} that should use a NOW
that represents the actual moment the request is made, even if they've been
tailing a cursor (with a sort that might not even involve {{expiresAt}})
continuously
I've added a note about sorts (implicitly) involving NOW to the docs on
cursors...
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=38572235&selectedPageVersions=28&selectedPageVersions=29
> Cursor value always different for last page with sorting by a date based
> function using NOW
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-10231
> URL: https://issues.apache.org/jira/browse/SOLR-10231
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
> Affects Versions: 4.10.2
> Reporter: Dmitry Kan
>
> Cursor based results fetching is a deal breaker for search performance.
> It works extremely well when paging using sort by field(s).
> Example, that works (Id is unique field in the schema):
> Query:
> {code}
> http://solr-host:8983/solr/documents/select?q=*:*&fq=DocumentId:76581059&cursorMark=AoIGAAAAAC5TU1ItNzY1ODEwNTktMQ==&fl=DocumentId&sort=UserId+asc%2CId+desc&rows=1
> {code}
> Response:
> {code}
> <response>
> <lst name="responseHeader">
> <int name="status">0</int>
> <int name="QTime">4</int>
> <lst name="params">
> <str name="q">*:*</str>
> <str name="fl">DocumentId</str>
> <str name="cursorMark">AoIGAAAAAC5TU1ItNzY1ODEwNTktMQ==</str>
> <str name="fq">DocumentId:76581059</str>
> <str name="sort">UserId asc,Id desc</str>
> <str name="rows">1</str>
> </lst>
> </lst>
> <result name="response" numFound="1" start="0"/>
> <str name="nextCursorMark">AoIGAAAAAC5TU1ItNzY1ODEwNTktMQ==</str>
> </response>
> {code}
> nextCursorMark equals to cursorMark and so we know this is last page.
> However, sorting by function behaves differently:
> Query:
> {code}
> http://solr-host:8983/solr/documents/select?rows=1&q=*:*&fq=DocumentId:76581059&cursorMark=AoIFQf9yCCAAAAAuU1NSLTc2NTgxMDU5LTE=&fl=DocumentId&sort=min(ms(NOW,DynamicDateField_1),ms(NOW,DynamicDateField_12),ms(NOW,DynamicDateField_3),ms(NOW,DynamicDateField_5))%20asc,Id%20desc
> {code}
> Response:
> {code}
> <response>
> <lst name="responseHeader">
> <int name="status">0</int>
> <int name="QTime">6</int>
> <lst name="params">
> <str name="q">*:*</str>
> <str name="fl">DocumentId</str>
> <str name="cursorMark">AoIFQf9yCCAAAAAuU1NSLTc2NTgxMDU5LTE=</str>
> <str name="fq">DocumentId:76581059</str>
> <str name="sort">
> min(ms(NOW,DynamicDateField_1),ms(NOW,DynamicDateField_12),ms(NOW,DynamicDateField_3),ms(NOW,DynamicDateField_5))
> asc,Id desc
> </str>
> <str name="rows">1</str>
> </lst>
> </lst>
> <result name="response" numFound="1" start="0">
> <doc>
> <str name="DocumentId">76581059</str>
> </doc>
> </result>
> <str name="nextCursorMark">AoIFQf9yFyAAAAAuU1NSLTc2NTgxMDU5LTE=</str>
> </response>
> {code}
> nextCursorMark does not equal to cursorMark, which suggests there are more
> results. Which is not true (numFound=1). And so the client goes into infinite
> loop.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
