svn commit: samba r17372 - in branches/SOC/mkhl/ldb-map/modules: .

[Martin Kühl]

On 8/4/06, Andrew Bartlett <abartlet at samba.org> wrote:
> On Fri, 2006-08-04 at 07:25 +1000, Andrew Bartlett wrote:
>
> > > > @@ -2242,9 +2269,8 @@
> > > >
> > > >         /* XXX: ugly kludge
> > > >         ac->local_attrs = local_attrs;
> > > > +       */
> > > >         ac->remote_req->op.search.attrs = remote_attrs;
> > > > -       */
> > > > -       ac->remote_req->op.search.attrs = NULL;
> > > >
> > > >         /* split local from remote tree */
> > > >         ret = partition_tree(module, ac->remote_req, ac,
> > >
> > > When checking a search result against the original parse-tree, I
> > > wanted to have all attributes of the record available, which is why I
> > > set the searched attributes to NULL here.
> > > Can you tell me the reason you wanted this change?
> >
> > I need to get at additional attributes, which are operational, and
> > therefore don't show up until you ask for them.
>
> The correct approach is (if we need to look in the local db at all) is
> to add the attributes you need to search on in the the remote search
> tree to the list of attributes (then remove them before passing them to
> the caller).

I got started with this in r17422, does that work well enough for you?

> While the local DB is key to making this work, I really want it to be a
> last-resort thing, with partitions and other games used to put most of
> the complex problems out of the way.

I'm not quite sure what you mean here.
The local DB should only be in use currently if the mapping encouters
attributes that are unknown to it, or that we are explicitly told to
ignore.  How it is actually used and how we use partitions for the two
DBs should maybe be a little less exposed though.

> As regards your recent shake up, I think I only need one change (not yet
> tested).  This ensures that on 'keep' attributes, we don't change the
> name.  (Otherwise, attributes caught by the "*" wildcard record get
> renamed to "*").

That should be in, thanks for the patch.  And sorry about the stir...

> I also need an extra feature.  I want a way to add exensibleObject to
> the end of every objectClass list (and remove it again on the search).
> This will ensure I can get around the painful OpenLDAP schema
> restrictions.

I took a stab at that in r17427, but I don't really like the
brute-force way of simply adding that objectClass to all records.
Maybe we could put the infrastructure for objectClasses to use here
and add "extensibleObject" if a records data doesn't quite match the
mapped objectClasses?  (Not that that would do anything to simplify
your small test, but still...)

Cheers,
Martin