Re: general aliasing

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

Robert Streich wrote:
> 
> Will,
> 
> I just made a quick scan of your code and I can't see how you include any
> subtrees that are referenced by aliases within the scope of the orignal
> search. For example, given
> 
>                                 a=1
>                                /   \
>                               /     \
>                              /       \
>                             /         \
>                          b=1           b=2
>                         /   \         /   \
>                        /     \       /     \
>                       c=1   c=2     c=3   c=4
>                      /   \
>                     /     \
>                    d=1   d=2
> 
> If you're doing a subtree-scope search of base of "b=1" (I'll just use RDNs
> for shorthand) and "d=2" is an alias for "b=2" then you have to include the
> "b=2" subtree in the original search. This is what I was referring to when
> I talked about modifying the search filter. You have to first find all
> of the aliases within the scope of "base," find any additional vertices
> that need to be included in the search, and then "or" in scoping filters
> for the additional vertices. This means that you also have to change the
> scoping tests when verifying the candidates.

That raises a good question, should the deref return a candidate that
contains a DN that is not within the requested base and fails the
original base and scope checks.  My original instinct was no, the
required base and scope should be adhered to or the client may be
confused, but perhaps I am wrong.  Anyone else have comments on this?

If it should return this then it should be relatively straight forward
to change the code.  The derefAlias would need to go before the filters
and part of its deref process for an entry would be to determine
candidate alternate bases.  These could then be part of the filter and
scope check.

> I also noticed at least one memory leak where you dup "base" into "realBase"
> and then later assign to realBase without freeing the duped string.

thanks, fixed.  

> Since you were working with suffixes, maybe you can answer a question for
> me. I don't see why in subtree_candidates() it doesn't add a scoping filter
> if "base" is a suffix. Do you know the logic behind this?

for subtree, if base is a suffix, the scope is the whole tree.
 
-- 
Will Ballantyne             GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca