[
https://issues.apache.org/jira/browse/OPENJPA-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110807#comment-18110807
]
ASF subversion and git services commented on OPENJPA-2964:
----------------------------------------------------------
Commit 17da2c470eb7f5dc8e6c1ccecc1aa2458bd078d9 in openjpa's branch
refs/heads/OPENJPA-2964 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=17da2c470 ]
[OPENJPA-2964] Honour the query range on set operations
executeSetOperatorQuery() received the StoreQuery.Range but never used it,
so setFirstResult()/setMaxResults() were silently ignored on a UNION,
INTERSECT or EXCEPT query.
The range is applied in memory over the compound result, through
RangeResultObjectProvider, which is the same fallback the ordinary path
uses when the dictionary cannot express a range in SQL. It cannot be
pushed into the statement: DBDictionary.toSelect() renders the first
operand in full, including any limit derived from the select's start and
end index, and only then appends the set operator buffer, so a range on
the main select would bind to the first operand instead of to the
compound result. A javadoc on the method records that, since the
optimisation is tempting and silently wrong.
testSetOperatorRange covers UNION ALL, UNION, INTERSECT and EXCEPT, and
both provider branches. It asserts cardinality only: JPQL attaches an
ORDER BY to an individual select, so the row order of a compound set
operation is undefined.
> Range ignored in executeSetOperatorQuery
> ----------------------------------------
>
> Key: OPENJPA-2964
> URL: https://issues.apache.org/jira/browse/OPENJPA-2964
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683002267
> **(medium)** `executeSetOperatorQuery` receives `range` but never uses it, so
> `setFirstResult`/`setMaxResults` on a UNION/INTERSECT/EXCEPT query are
> silently ignored. Should the range at least be applied via
> RangeResultObjectProvider like the normal path does?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
