Extending LDB for Extended DNs

[simo]

On Wed, 2008-12-03 at 11:35 +1100, Andrew Bartlett wrote:
> On Fri, 2008-11-21 at 18:28 +1100, Andrew Bartlett wrote:
> > On Fri, 2008-11-14 at 18:23 +1100, Andrew Bartlett wrote:
> > > On Wed, 2008-11-05 at 22:33 +1100, Andrew Bartlett wrote:
> > > > Great.  I've been working on this hard for the past week or so.  See
> > > > http://gitweb.samba.org/?p=abartlet/samba.git/.git;a=shortlog for the
> > > > current work in progress.
> > > > 
> > > > I'm currently working on the comprehensive testsuite for DN behaviours,
> > > > particularly with the extended DNs.
> > > > 
> > > > I would appreciate any comments or feedback,
> > > 
> > > This work has taken far, far longer than I ever expected, but it seems
> > > that a SID or a GUID is just as valid as a DN in *every* area where it
> > > is used.  As such, a fairly major rework has been required to translate
> > > these into a 'normal' DN.
> > > 
> > > I've not yet got a working 'store the full DN' module working, but I
> > > have largely got the input side working, and make test passing (broken
> > > again as I test more, but what was there passes).  I've updated my GIT
> > > tree again. 
> > > 
> > > This looks like taking another week to finish, after which I hope to
> > > publish another Samba4 alpha. 
> > 
> > I've updated my git branch again.  I'm almost finished - I just need to
> > figure out why subtree renames are no longer updating the linked
> > attributes. 
> > 
> > Next steps are to hook this in to metze's DRS translation layer and to
> > hook into OpenLDAP's 'dereference control'.
> > 
> > Once this is in and tested, we should be in a good position to make the
> > long-awaited alpha6 release, which will then, I hope, support Samba3 as
> > a member server.
> 
> I've now completed the work - it passes 'make test' (albeit without the
> LDAP backend).  Is there any objection to me merging the work, as seen
> in the branch above?
> 
> (And no, I'm not willing to rebase it - sorry.  It would remove a lot of
> the context of the changes and make a bisect harder). 

A merge would probably be horrible, a rebase is highly preferable and
will allow for a final check on the patchset before we put it in.

If git rebase does not work for you diff+patch is good as well.

Anyway I would not put it in if it is going to break the LDAP backend,
we should have it working for.
I have gone through great pain myself to make sure my stuff did work
with LDAP with the async patches, is there a reason to apply a different
standard in this case ?

Finally have you run the ldb speed tests with and without your patches?
Is there any difference ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>