[SAMBA4] Using ldb_map for pure translations

[Martin Kühl]

On 8/2/06, Andrew Bartlett <abartlet at samba.org> wrote:
> On Wed, 2006-08-02 at 00:49 +0200, Martin Kühl wrote:
> > On 8/1/06, Andrew Bartlett <abartlet at samba.org> wrote:
> > > I started on an entryUUID module, but I'm wondering if we should either
> > > have lots of extra logic in the current ldb_map to cope with never
> > > reading a local database, or create a new module, sharing many of the
> > > support routines (which replace values in the parse tree).
> >
> > I'm not sure if it would really require lots of extra logic.
> > The largest subproblem seems to be handling of attributes without an
> > associated mapping.  My first reaction was to propose "catch-all"
> > mappings of a form like
> >     .local_name = "*",
> >     .type = MAP_KEEP,
> > but as the only sensible choices here seem to be MAP_KEEP and
> > MAP_IGNORE (which is implicitly used right now), we could just
> > parameterize the module with this choice.
>
> I'll do that.  I have a slightly different hack at the moment.
>
> > With that in place, targeting only a single partition would be
> > immediate for add/modify requests (as the local message would always
> > be empty) and could be done easily for the other requests (with a test
> > whether the base DNs are equal, say).
> >
> > I'm hesitant about sharing the support routines because the
> > differences between our intentions would affect both high- and
> > low-level routines and we would be limited to sharing those in
> > between.  That said, the request handling should be a lot easier for a
> > single partition, so only the low-level routines would need to be
> > changed, and ripping out the mapping routines should make the current
> > module less unwieldy.
> > Still, I think I prefer the former option.
> >
> > > My initial attempts are attached.
> > >
> > > What do you think?
> >
> > They're looking pretty straightforward.  And make me think of a whole
> > bunch of problems one will run into when the local and remote base DNs
> > are equal, so thanks for raising the issue.
>
> Yeah :-)
>
> > Any specific reason you pushed the call to `find_local_attr' down into
> > `partition_msg_el'?
>
> To get the name, because if we have a wildcard mapping, the map.name
> would be "*".
>
> > > If we can make this work, I would like to merge your ldb_map code into
> > > the mainline.  What is the best way to do this?
> >
> > I'm still working on an issue with parse-trees, and I'd like to clean
> > the module up a little (rename/reorder functions, use fewer gotos,
> > maybe add section headers), but should be done in one or two days.
> > After that, I can supply a patch to the list for review (and bashing
> > my coding style :-).  And eventually, someone (me?) might merge my
> > branch(es).
>
> What are the open issues with parse trees?  I'm playing with this today,
> and knowing the landmines could be useful...

Consider a search expression "(|(left=foo)(right=bar))" where left is
a local and right a remote attribute.  If I just split the tree I'll
end up with a remote search for "(|(right=bar))", leaving out records
that match the left=foo part.
I'm going to just enumerate the remote partition in those cases, but I
still need to identify them correctly.

Martin