On Wed, Feb 16, 2011 at 3:23 AM, Emmanuel Lecharny <[email protected]> wrote: > On 2/15/11 9:52 PM, Kiran Ayyagari wrote: >> >> On Wed, Feb 16, 2011 at 2:15 AM, Kiran Ayyagari<[email protected]> >> wrote: >>> >>> On Wed, Feb 16, 2011 at 1:50 AM, Emmanuel Lecharny<[email protected]> >>> wrote: >>>> >>>> On 2/15/11 9:15 PM, Kiran Ayyagari wrote: >>>>> >>>>> On Wed, Feb 16, 2011 at 12:39 AM, Emmanuel >>>>> Lecharny<[email protected]> >>>>> wrote: >>>>>> >>>>>> On 2/15/11 8:00 PM, Kiran Ayyagari wrote: >>>>>>> >>>>>>> On Tue, Feb 15, 2011 at 8:53 PM, Emmanuel >>>>>>> Lecharny<[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> the compareTo method has a semantic that probably does not applies >>>>>>>> to >>>>>>>> the >>>>>>>> Dn >>>>>>>> class : either two DNs are equals, or they are different, but they >>>>>>>> aren't >>>>>>>> superior or inferior, except if one is the parent of the other. >>>>>>>> >>>>>>>> As we already have a isParent and isChild methods, I suggest we >>>>>>>> remove >>>>>>>> the >>>>>>>> compareTo() methods (which is never used) and not implemen the >>>>>>>> Comparable<Dn> interface. >>>>>>>> >>>>>>> I suggest we keep this, think of ordering the Entry objects while >>>>>>> performing an export >>>>>>> (sorting a huge number of entries won't be the ideal case, but when >>>>>>> we >>>>>>> have a few entries which are fetched in an adhoc manner(i.e without >>>>>>> performing repetitive one level searches)) >>>>>> >>>>>> The thing is that there is no way to order a list of DNs, as there is >>>>>> no >>>>>> such a MatchingRule as DnOrderingMatch. How do you order two DNs which >>>>>> RDN >>>>>> don't have the same AttributeType ? >>>>>> >>>>>> I have checked RFC 4517, and after having read it, I saw that >>>>>> comparing >>>>>> two >>>>>> DNs is just meant to check that they are equal, or not. No order is >>>>>> implied. >>>>> >>>>> how about using the isParent() and isChild() methods for that inside >>>>> the compareTo() >>>> >>>> yes, but still it's not possible to compare 2 DNs with the same >>>> parent... >>>> CompareTo() for DNs simply does not make sense :) >>> >>> hmmm, just wondering why can't we compare the normalized values(which >>> are strings) of two DNs >> >> by the above I mean for equality, and we have isParent() if it is >> higher in hierarchy and isChild() otherwise, >> I see that semantically it doesn't make *much* sense to say 'compare >> two DNs' but still we can *order* DNs and >> that is where this method is helpful > > Let me give you an example. > > You have two DN under the same parent, dc=example,dc=org : > > dn1 : cn=test,dc=example,dc=org > dn2: telephoneNumber=+33 1 654 321 02,dc=example,dc=org > > you have no clue about which DN is greater or lower than the other, as the > cn matching rule is CasIgnoreMatch and the TelephoneNumberMatch MR is used > for the second DN. > > This is the reason whu comparing two DN to define an ordering is just vain. > yeap, agree, but I was thinking a bit more about the problem of ordering entries (by the user of API), here the semantics of compareTo() are based on the level of DN in the DIT rather than the values that make the DN. This was my idea of comparing two DNs, but it is not in line with the traditional use/semantics of compareTo() method, a 'Note' in the javadoc would help or if it sounds like not a good choice +1 for removal. > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
-- Kiran Ayyagari
