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

[Jan Cholasta]

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.

Honza

-- 
Jan Cholasta