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

[Petr Viktorin]

On 01/17/2013 04:17 PM, Petr Viktorin wrote:
> On 01/17/2013 02:40 PM, Jan Cholasta wrote:
>> On 17.1.2013 12:46, Petr Viktorin wrote:
>>> On 01/17/2013 09:07 AM, Jan Cholasta wrote:
>>>>
>>>> While this works for dict, I'm not sure if it applies to *all*
>>>> dict-like
>>>> classes that we use.
>>>
>>> I don't think we have any classes where it doesn't apply.
>>>
>>>> Once we completely get rid of entry tuples, we can reintroduce a
>>>> dict-like __iter__. IMO new code should not be punished (i.e. forced to
>>>> use .keys()) for the crimes (i.e. tuples) of the old code.
>>>
>>> Yes, eventually. Though I'd like it to raise an exception for some time,
>>> so any external plugins that rely on it fail rather than get bad data.
>>
>> OK. But I think external plugins will break either-way, as we don't
>> really maintain backward compatibility in our internal APIs.
>>
>>>
>>>> We should decided whether we want to use entry['dn'] or entry.dn and
>>>> use
>>>> only that in new code. I like entry.dn more, as it better
>>>> corresponds to
>>>> the special meaning of dn in entries.
>>>
>>> I also like entry.dn, at least in most cases, but if we don't
>>> synchronize them then we need to remove entry['dn'] completely. Having
>>> misleading/stale data in the object isn't good.
>>> There are some cases where entry['dn'] makes sense, such as iterating
>>> over all attributes.
>>> If we're going to have validation for every attribute anyway, I don't
>>> think synchronizing the two would be a major problem. Especially since
>>> entry.dn is already a property.
>>>
>>
>> OK, we will deal with that in further patches.
>>
>> Updated patch attached.
>>
>> Honza
>>
>
> ACK. I'll start working on top of this.
>

FYI: this patch was pushed to master as part of the big LDAP refactoring 
push.
See https://fedorahosted.org/freeipa/ticket/2660 for details.


-- 
Petr³