What are you implementing Comparable on? I would suggest creating a Customer type,
and having that implement Comparable, or even
better providing a number of Comparators for the various columns you're after.
So in your Customer class, I would have an inner class like:
public static final Comparator CUSTOMER_COMPARATOR = new Comparator()
{
/**
* Compares two Customers, comparing first by name, then by address, then by
city.
*/
public int compare(Object o1, Object o2)
{
Customer c1 = (Customer) o1;
Customer c2 = (Customer) o2;
// compare names
int n = c1.getCustomerName().compareTo(c2.getCustomerName());
// if names are not the same, return the order based on names.
if (n != 0) return n;
// compare addresses
int a = c1.getAddress().compareTo(c2.getAddress());
// if addresses are not the same, return the order based on addresses.
if (a != 0) return a;
// compare cities.
int c = c1.getCity().compareTo(c2.getCity());
// if cities are not the same, return the order based on cities.
if (c != 0) return c;
// names, addresses and cities are the same, they must be ordered the same.
return 0;
}
}
however, I wouldn't be 100% sure that this will be faster than a trip to the db....
might be worth testing, might not, depends how
many Customers you have in your collection.
also - I'm assuming you dont want to include customerId in the sort, as I'm assuming
thats a primary key.
hth
cheers
dim
----- Original Message -----
From: "D H" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 24, 2002 2:31 PM
Subject: SFSB Sorting!
> Hi All,
>
> I have a SFSB which gets loaded with database
> resultsets whenever user makes some searches and this
> is for per use, not per application. The SFSB has
> attributes like:
>
> String CustomerId
> String CustomerName
> String Address
> String City
>
> When I display the search result, I allow the fields
> to be sortable (ASC/DESC). And the sorting I like to
> do it in memory since it is already in Session scope,
> instead of travel back to database with different
> ORDER BY clause, and the backend data is pretty static
> per day. And in my sort algorithm, I like it to take
> care like in database ORDER BY field1, field2, field3,
> field4 whereby not only the actual field but with
> composite to be sorted. If I implement Comparable,
> compareTo only takes care of per single field not the
> composite.
>
> And the second one is could you give some pointers in
> what sorting algorithms would be faster for this
> scenario � the resultset size would be less then 10k
> for the field size of 5-6, String datatype?
>
> Thanks!
>
> __________________________________________________
> Do You Yahoo!?
> Great stuff seeing new owners in Yahoo! Auctions!
> http://auctions.yahoo.com
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
