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
