[Freeipa-devel] [PATCH] 93 Add custom mapping object for LDAP entry data

[Petr Viktorin]

On 01/22/2013 08:31 AM, Jan Cholasta wrote:
> On 21.1.2013 17:46, Petr Viktorin wrote:
>> On 01/21/2013 04:48 PM, John Dennis wrote:
>>> On 01/16/2013 10:45 AM, Jan Cholasta wrote:
>>>> Hi,
>>>>
>>>> this patch adds initial support for custom LDAP entry objects, as
>>>> described in <http://freeipa.org/page/V3/LDAP_code>.
>>>>
>>>
>>> Just in case you missed it, I added some requirements to the above
>>> design page about making LDAP attributes and their values be "smarter".
>>
>> It would be nice to discuss these changes on the list, since the
>> implementation is already underway...
>>
>>> An LDAP attribute has a syntax defining how comparisons are to be
>>> performed. Python code using standard Python operators, sorting
>>> functions, etc. should "just work" because underneath the object is
>>> aware of it's LDAP syntax.
>>>
>>> The same holds true for attribute names, it should "just work" correctly
>>> any place we touch an attribute name because it's an object implementing
>>> the desired comparison and hashing behavior.
>>>
>>> Thus the keys in an Entry dict would need to be a new class and the
>>> values would need to be a new class as well. Simple strings do not give
>>> rich enough semantic behavior (we shouldn't be providing this semantic
>>> behavior every place in the code where we touch an attribute name or
>>> value, rather it should just automatically work using standard Python
>>> operators.
>>
>> I think plain strings are fine for attribute names, as long as the entry
>> class handles them correctly. We don't really need to hash or compare
>> them outside of an entry. Or at least not enough to warrant a special
>> class, IMO.
>> Of course Entry.keys() and friends should return normalized names that
>> would sort/hash correctly.
>
> +1
>
>>
>>
>> As for attribute values, you're right that LDAP specifies how they
>> should be compared, but that's only in the context of a single attribute
>> type. What happens when you try comparing a case-sensitive string to a
>> case-insensitive one in Python?
>>
>
> I would say TypeError. But I don't think we should be too strict in
> following the schema, it's too much work for questionable benefit. As
> you pointed out, it might bring problems for which there is no right
> solution.
>

Well, instead of "compares equal" you can say "have same hash":

If you make "abc" == Insensitive("abc") == "ABC", then "abc" and "ABC" 
must hash the same, which they don't.

If you make "abc" != Insensitive("abc") != "ABC", then I can't say 
entry["abc"].


-- 
Petr³