directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Dn should probably not implement Comparable
Date Wed, 16 Feb 2011 05:35:01 GMT
On Wed, Feb 16, 2011 at 3:23 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> On 2/15/11 9:52 PM, Kiran Ayyagari wrote:
>>
>> On Wed, Feb 16, 2011 at 2:15 AM, Kiran Ayyagari<kayyagari@apache.org>
>>  wrote:
>>>
>>> On Wed, Feb 16, 2011 at 1:50 AM, Emmanuel Lecharny<elecharny@gmail.com>
>>>  wrote:
>>>>
>>>> On 2/15/11 9:15 PM, Kiran Ayyagari wrote:
>>>>>
>>>>> On Wed, Feb 16, 2011 at 12:39 AM, Emmanuel
>>>>> Lecharny<elecharny@gmail.com>
>>>>>  wrote:
>>>>>>
>>>>>> On 2/15/11 8:00 PM, Kiran Ayyagari wrote:
>>>>>>>
>>>>>>> On Tue, Feb 15, 2011 at 8:53 PM, Emmanuel
>>>>>>> Lecharny<elecharny@gmail.com>
>>>>>>>  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

Mime
View raw message