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

[Petr Viktorin]

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.


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?

-- 
Petr³