Rob Crittenden wrote:
Pavel Zuna wrote:
ldap2._generate_modlist now uses more sophisticated means to decide when to use MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did MOD_REPLACE only on attributes explicitly specified in ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now it does MOD_REPLACE for all single value attributes and never for multi value.

This patch also silently fixes a bug: ldap2 didn't check for the existence of attributes that were being deleted by setting them to None.

Pavel

I still need to try this patch out but I came up with a few questions.

Is schema something that needs to be passed in? This needs to be a python-ldap Schema object, right? Should that be enforced?
A schema will only be passed in, if someone wants to connect to an LDAP server that uses a different schema than the IPA DS. We might of course enforce it to be a subclass of the Schema class, but I don't like enforcing stuff, so I'm not used to do it. :)

Will this blow up if the call to self.schema.get_obj(_ldap.schema.AttributeType, k) fails?
No, it will just assume the attribute is multi value. If the schema object is valid, it shouldn't fail unless we try to get an attribute that isn't in the schema.

As an aside, not related to this patch, I noticed that debug_level defaults to 255 which seems wrong. It isn't a problem because this argument isn't used at all.
That's probably a leftover from long ago. I'll remove it (or use it with a more appropriate value) in the next patch on ldap2.

rob

Pavel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to