rzo1 opened a new pull request, #172: URL: https://github.com/apache/openjpa/pull/172
`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 through `RangeResultObjectProvider`, 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, returning wrong rows rather than none. 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, asserting cardinality only: JPQL attaches ORDER BY to an individual select, so the row order of a compound set operation is undefined. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
