Extending LDB for Extended DNs

[Andrew Bartlett]

On Thu, 2008-11-06 at 08:22 -0500, simo wrote:
> On Thu, 2008-11-06 at 19:18 +1100, Andrew Bartlett wrote:
> > 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. 
> 
> I am not sure I understand what you mean.

I'll rework the code to treat 'extended dn' as optional, and parse from
this if available.  

> > > 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. 
> 
> ldb_dn is opaque so that we can do optimizations once and avoid problems
> with people playing with the struct, sure the talloc_free can be easily
> taken correctly in account.

I'll look into having extended_dn be NULL and ignored if unused.

> > >  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?
> 
> torture local dbspeed

Thanks.  I'm pretty sure this will all be in the noise. 

Andrew Bartlett

-- 
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/20081107/f696df44/attachment.bin