> is it so hard to do? It's not very efficient, I guess. Please note that Slice currently does work for a) range queries b) order by queries across multiple slices. These facilities do work in similar algorithm you had outlined. They are also efficient in merging/ordering several lists that are themselves ordered. It is the cross-section of (merging + ordering + applying a range) that is broken.
The problem is not hard per se. The factor is Slice had followed throughout a composite design pattern. That is to say that Slice is implemented with minimal code of its own. It simply leverages all the code of core OpenJPA kernel and provides a composite layer on top of that. OpenJPA kernel has facilities of handling query results from multiple results or ordering them. Slice simply makes a judicious usage of these facilities. In such usage, *something* is amiss while merging + ordering + range operations are applied simultaneously. I am sorry that I do not have sufficient bandwidth currently to investigate it further that being vague about "something*. But the is quite likely hidden in the way the core OpenJPA facilities operate while merging+ordering+range operation The relevant code for these operations are in 1. org.apache.openjpa.slice.jdbc.DistributedStoreQuery$ParallelExecutor#executeQuery(...) 2. org.apache.openjpa.kernel.OrderingMergedResultObjectProvider 3. org.apache.openjpa.lib.rop.RangeResultObjectProvider 4. org.apache.openjpa.lib.rop.MergedResultObjectProvider Some brave code warrior needs to take a look. ----- Pinaki Poddar Chair, Apache OpenJPA Project -- View this message in context: http://openjpa.208410.n2.nabble.com/Slice-setFirstResult-with-setMaxResults-broken-tp6695977p6712270.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
