Darius --
I don't think there's anything that can be done by implementing
Comparable that can't be done with a custom comparator, it's just that either
the files proliferate or you end up with multiple copies of contained custom
comparator classes (calculating collation collectively).
It's really concern with warnings that problems can arise with
maps when compareTo and equals are inconsistent that caused me to post. I can
follow Ben's idea and make them consistent. However, if I read you correctly,
by implementing Comparable, I'm essentially declaring a natural key that could
be used in more ways than I will know about; if all I'm after is sorted output,
I should just sort it as it's going out the door, not do something that will
impose that sort order on every set operation.
Saludos, Roger
From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri
Sent: Monday, January 23, 2012 12:41 PM
To: [email protected]
Subject: Re: [OPENMRS-DEV] Equals and Compare for OpenMRS objects
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]<mailto:[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]<mailto:[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<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[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]
