Oct 23rd, 2009, 08:04 AM
Thoughts on Sorting
In Stefan's talk at SpringOne on ROO, he asked for feedback on sorting colums on the web list forms.
I've been pondering, and I think the answer is this:
1) Object sorting first. Get object (memory) sorting working first. Why? To enable sorting on calculated and/or joined-in columns right away (version 1.0). Again, something that doesn't do what you need it to is 0% optimized. And not being able to sort on calculated columns out if the box in Grails makes me crazy.
2) 'Dumb' optimized sorting second. If it's a raw DB column, and the resultSet is over a configurable-via-annotation/EL threshold, then sort in the DB. Otherwise, sort the in-memory set.
3) 'Smart' optimized sorting third. Use DB heuristics or some other figure-it-it in the fly way of figuring out which way to sort it.
Make sense? For a system like ROO, being able to OOTB sort on 'anything' is the number 1 priority, I think, even if it's not 'optimized' in version 1...
Last edited by TimWhite; Oct 23rd, 2009 at 08:07 AM.
Oct 23rd, 2009, 10:01 PM
First, thanks for getting this discussion started!
I am a little unclear what exactly you are proposing here however. Can you please elaborate a little more (maybe even give a code example)?
As far as I can see there are three options available:
2. Sort in the DB using ORDER BY. This is most efficient if you assume that the datasets are really large.
3. Sort cached resultsets in the controller which, if I remember right, has some support in Spring MVC.
I am sure there are more options...
Oct 23rd, 2009, 10:17 PM
I vote for option 2 "Sort in the DB using ORDER BY. This is most efficient if you assume that the datasets are really large.".
Oct 23rd, 2009, 10:34 PM
Hi, sorry for any confusion.
I think the best long-term approach is a hybrid. If you have only one page worth of data, it's fastest to sort it in the .js tier.
If you have a few hundred records, it's probably fastest in the middle tier.
If you have thousands of records, it's probably fastest in the DB.
That covers performance, but it's flexibility that I was trying to get at.
If you are only sorting with ORDER_BY in the DB, you can only sort directly-mapped DB columns. Calculated fields (other than ones calculated in the DB), or in some cases, joined fields, can't be easily sorted with ORDER_BY, meaning you have to have a hybrid approach for them as well.
My suggestion was to go with the most flexible option (which I think is Controller sorting), in ROO 1.0, and implement the hybrid .js/Controller/DB sorting in future releases.
Oct 26th, 2009, 03:48 PM
I'm in favor of #2. In our current project we have had to introduce some JPA classes between join tables just to allow us to have sorted JPA sets.
Oct 27th, 2009, 08:25 AM
I see two diferent use case scenarios for sorting.
First, user want a (large) amount of sorted data, for example a findUserByIncome finder.
Second, user is simply viewing data and want to sort it in diferent ways depending on situation and the moment.
For the first scenario my vote goes to orderBy.
In the second i think the best aproach is sorting in the controller/client without doing aditional querys to database, via ajax if possible.
Controller sorting makes it easily customizable for java developers, while client sorting makes it fastest, i think user should be able to choose between one or another, for example using a sortType property.
My two cents
Oct 27th, 2009, 01:19 PM
For me, just being able to set an *initial* sort order on the queries would be a big help. Next would be allowing OrderBy to be set dynamically (passed from ui->controller->entity manager) to allow sortable columns and pagination on larger data sets. That's probably also something a lot of people are used to having with various frameworks.
On the other sorting types:
UI sorting: There are many available tools for implementing sorting on the ui. Would be cool to see in the scaffolding, but maybe not necessary.
"Java" sorting: I'm not sure about this one. I can see the usefulness, and the Roo team would be adored for solving it. But it seems complicated - I'm happy to implement comparable myself when I need to. Maybe Roo can make it possible to "call" sort on a collection, but leave the actual compareTo method up to me?
Tags for this Thread