ORDER BY is not regconized in JBoss 4.0 DR2
(Perhaps tihis should be in the design patterns forum, but I think it's appropriate here as well).
For a while we have struggled with the design pattern for basic list processing (paging back and forth through data, potentially thousands of records) using CMP. Normally we only display e.g. 20 records. The aim is of course to be portable across app servers.
The way that the Collection works which is returned from finder methods when using JBoss is really good, if I understand it right. It is acting as a dynamic facade to the ResultSet. So, I execute a finder method, and a Collection is returned to me, but all the elements haven't been filled in. Depending on tuning parameters, maybe only a few of the elements have been filled in.
However, if I ask for the size() of the collection, it returns the correct result, i.e. the total number of records in the result set, which I guess is being done by consulting the result set at the back end.
Great. So what I would want to do now, for really easy paging functionality is just record as hidden values on my form the start and end index of what I read from the collection. To page forward, I run the finder again, and just retrieve from lastIndex+1 up to lastIndex+pageSize.
But of course, the Collection interface doesn't support that. If it was a java.util.List, I could retrieve a subList of the required elements.
(of course there are some issues there - if records had been inserted in the meantime, my index positions would not be accurate, but I'm prepared to live with that).
Without this ability, I have to resort to the following:
- store first and last indexes of things I am ordering by as hidden values on the form
- use two finders (one for paging forwards, and one for paging backwards) that must use JBossQL extensions, specifically the use of > or < on a String value (ANGER - I ABSOLUTELY CANNOT BELIEVE THAT THE EJB-QL SPEC DOESN'T ALLOW THAT!).
I want to be portable. Allowing java.util.List as the return type of a finder method would allow that, I believe (would force all vendors to support the subList).
What does everyone think? Am I missing the point here? Should I be approaching the whole topic differently?
Or would this be a valuable change to the spec?
