[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Duplicate Entry Control Patch (ITS#2113)

> Pierangelo,
> First of all, thanks for reviewing the patch. I will incorporate your
> patch with the current HEAD code and re-submit soon.

I suggest you enable the paged result stuff (I think it's enabled
by default in current HEAD, the appropriate macro is in include/ldap.h)

This stuff creates a sort of chicken-and-egg problem with your stuff,
because the paging must stay in the backend to be able to resume from
the point where the last page stopped; however, if you dup an entry
after page-counting, you break the page counting.  I know it's shooting
in one's foot to use the two controls simultaneously; we might well
come out with refusing to accept them in the same request, but
I'd like you to consider the problem.  After all paging is standard
track, while dupent is still draft ...

>>The patch looks fine; however its behavior has some quirks I'd like to
>> investigate.
>>- as appears from your search.out example, after returning duplicate
>> entries for each value of the dupent attr, a final entry with the first
>> value and all the other requested attrs is returned.  I didn't read
>> draft-ietf-ldapext-ldapv3-dupent-08.txt too carefully; is it intended?
> I've just reviewed the search.out file and there seems to be an error.
> The draft states that all duplicated entries should be sent as separate
> entries with a DuplicateSearchResult control. However, in the search.out
> file, "member:cn=Manager,o=University of Michigan,c=US" should not have
> been included in the non-duplicated list, since it has been sent already
> as a duplicated entry. I will fix that before re-submitting.

Looking forward to seeing the new version :)


Pierangelo Masarati