[
https://issues.apache.org/jira/browse/IGNITE-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346175#comment-17346175
]
Andrey Mashenkov commented on IGNITE-12291:
-------------------------------------------
[~timonin.maksim], you wrote:
{noformat}
So, I think, that number of pages to load can be limited with different
approach that described in the ticket description. We can move check of limit
to the `next()` call instead of `enqueue()`. After `next()` returns NULL
iterator automatically closes and send cancel requests to all nodes. {noformat}
You saves data into collection that will be never used.
What issue does the logic moving fix?
Lucene returns result sorted by relevance/score, but we might miss this
information somewhere.
> Create controllable paged query requests / responses for TextQuery similar to
> current SQL result processing
> -----------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-12291
> URL: https://issues.apache.org/jira/browse/IGNITE-12291
> Project: Ignite
> Issue Type: Improvement
> Reporter: Yuriy Shuliha
> Assignee: Maksim Timonin
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now query initiator node sends 1 _GridCacheQueryRequest_ and can get
> multiple _GridCacheQueryResponse_-s per remote.
> TextQuery processing finishes when all remotes send _GridCacheQueryResponse_
> with 'finished' flag.
> _TextQuery_ processing should be reworked like it was done for SQL queries.
> Ignite has _GridQueryNextPageRequest \ Response_ classes for SQL result
> processing.
> Similar processing should be implemented for _TextQueries_:
> *GridTextQueryNextPageRequest*
> *GridTextQueryNextPageResponse*
> Proper _TextQuery_ response processing should be implemented in
> _GridCacheQueryFutureAdapter._
> This will allow us to add correct sorting and apply limit correctly on reduce.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
