Extending LDB for Extended DNs

[simo]

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.

> > 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.

> >  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


Simo.

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