Roger, Do you really need that natural ordering? Or is it okay to do a collections.sort with a custom comparator (the one that does include your intended ordering) when necessary, and avoid implementing Comparable?
The general java issue is that once an object is in a collection, you need to be wary of modifying that object, or else the collection will be messed up. (Specifically, you can't change the hashcode of something that's in a HashMap/Set, and you can't change the sort order of something that's in a TreeMap/Set.) -Darius On Mon, Jan 23, 2012 at 4:45 PM, Ben Wolfe <[email protected]> wrote: > The .compareTo method is used when putting Comparables into sorted sets: > TreeSets, etc. As long as you are not falsely comparing two objects you > should be fine. Adding the uuid check to the end of your compareTo method > should do the trick. What you want to avoid is compareTo returning true > for two objects that have the same name but that have different uuids. > > IIRC, we had an issue at one point because we put the voided status in the > compareTo method. This meant that when you voided the object it suddenly > "disappeared" from sets because you couldn't compare the objects. > > FYI: Before 1.9 we were comparing using internal ids, so it was still an > identity test. The difference with 1.9 is that now the uuid is generated > at object creation time, so that we can safely compare a "new'd" object and > an object fetched from the db. > > Ben > > > On Sun, Jan 22, 2012 at 1:44 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < > [email protected]> wrote: > >> I hate to raise natural key/surrogate key again, but maybe there’s an >> easy answer to this question. With 1.9, we make all of our .equals >> routines compare uuids, which basically says that .equals is an identity >> test. I have started implementing Comparable on my data access POJOs >> because in many cases their natural order depends on names of concepts or >> locations referenced by the POJO, so I can’t sort on this order when >> returning a list of POJOs, instead I put the returned list through >> Collections.sort. However, this means that compare and equals are not >> consistent because the natural order may not be unique, and I understand >> this not to be a desirable situation. Is implementing Comparable a bad >> approach? Do I need to add ID or some other field to make the natural order >> unique? Is this not something to worry about?**** >> >> Saludos, Roger**** >> >> **** >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
