Extending LDB for Extended DNs

[Andrew Bartlett]

On Thu, 2008-11-06 at 00:58 -0500, simo wrote:
> On Thu, 2008-11-06 at 16:27 +1100, Andrew Bartlett wrote:
> > On Thu, 2008-11-06 at 00:17 -0500, simo wrote:
> > > On Thu, 2008-11-06 at 13:14 +1100, Andrew Bartlett wrote:
> > > > 
> > > > The patches have been rebased, and this is the result.  All of the
> > > > recent work in that branch represents the patches for this effort
> > > > (there
> > > > is a reason it has taken me a week)
> > > 
> > > Sorry I saw various "fix this detail" commits and I thought you didn't.
> > > You know you can squash "fix commits" into the original commit when you
> > > rebase ?
> > 
> > I know, and the last time I played with that it took much more time than
> > it was worth to get right, so I'm careful about doing it too much.  
> 
> Uh? Every time I do that it takes no more than a couple of seconds, just
> the time to replace 'pick' with 'squash', what kind of problem have you
> encountered in doing this ?

I had some re-bases fail, which was a right pain to sort out. 

> > > I have started reviewing the code, will get back to you when I have
> > > formed an opinion.
> > 
> > Thanks.  I'll keep writing tests, and hope to have this passing against
> > the extended 'make test' soon.
> 
> One question you can probably answer right away.
> Why do you fill the 'extended' parts of the ldb_dn structure by
> default ?

On the input side, it is basically the unparsed DN, as I have to push
what looks like the normal linearised DN to one side.  I don't want to
trust the 'initial' parser (where I look for the last >;) for untrusted
DNs.  That is why the full parser is run over the original string. 

> It seem to me a waste of resource (you duplicate memory even when
> extended and linearized are identical)

Yes, but would cause problems when we talloc_free() each them
separately. 

>  and time to always fill up all
> the 'extended' stuff even when no extended material is present (most
> common case for LDB).
> Maybe running a dbspeed test with and w/o the patches can tell if I am
> too paranoid or if there is an impact to the speed of ldb.

Got a pointer for the test that I should run?

Thanks,

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081106/5db50367/attachment.bin