s4:samldb LDB module - "member" trigger

[Andrew Bartlett]

On Sat, 2010-10-30 at 20:16 +0200, Matthias Dieter Wallnöfer wrote:
> The branch, master has been updated
>        via  c0ebf5d s4:sam.py - add a short double swap "primaryGroupID" test
>        via  98fefa8 s4:samldb LDB module - adapt the "samldb_prim_group_change" trigger to support multiple "primaryGroupID" modification entries
>        via  02355fc s4:samr RPC server - the LDB error codes for adding or deleting a group member have changed
>        via  c664f01 s4:sam.py - enhance "member" tests
>        via  4987467 s4:samldb LDB module - "member" trigger
>        via  5a2c3ad s4:rpc_server/common.h - quiet compilation warnings
>       from  b548674 provision: fix wrong tests
> 
> http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master

> commit 4987467b785a5870cb338881c8916b4268006cd6
> Author: Matthias Dieter Wallnöfer <mdw at samba.org>
> Date:   Sat Oct 30 17:12:48 2010 +0200
> 
>     s4:samldb LDB module - "member" trigger
>     
>     - adapt the "samldb_member_check" trigger to support multiple "member"
>       modification entries. There can exist special modification messages which
>       delete and add members in one operation
>     - support the right error codes when modifications do fail
>       (ERR_ENTRY_ALREADY_EXISTS, ERR_UNWILLING_TO_PERFORM)

Matthias,

Metze mentioned this patch to me on IRC as he chases down some
performance issues, and I wanted to comment on it.  He may make further
comments once he finishes pinning down his issue. 

The problem I have with the patch is that it seems very inefficient, and
I wondered if you had considered the O() notation complexity of this
validation.

For every member being added, you now do a search on the entry for that
member, rather than just let ldb_tdb complain about the duplicate
attribute when we eventually store it.  Why is this?  If an member
attribute gains 100 members, you now do 100 searches of the DB just to
check that they are not already there.  The cost of that search is
rougly proportional to the number of members already being added -
particularly if done one at at a time, so this seems to be O(n^2). 

And similarly, whey trying to determine if the member attribute would
conflict with a primaryGroupID, why not first (and only once) read the
sid of the entry, and then compare with the primaryGroupID of the
target?

Surely this would be faster than dereferencing the member attribute,
only to form up a SID and compare it with our own DN?

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101103/261448e1/attachment.pgp>