[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Duplicate entries filter
Date sent: Wed, 16 Aug 2000 10:31:18 -0600
From: "Jim Sermersheim" <JIMSE@novell.com>
To: <Kurt@OpenLDAP.org>,<d.w.chadwick@salford.ac.uk>
Copies to: <ietf-ldapext@netscape.com>
Subject: Re: Duplicate entries filter
> These examples do reflect the original intent of the I-D. While
> writing it, I had assumed the behavior previously discussed as a)
> (filter, duplicate, return). Given the usefulness of Kurt's example, I
> changed it to b) [filter, duplicate, filter, return (if your server
> can do this more efficiently, more power to ya)]. Then the notion of a
> flag was introduced.
Jim,
two points
i) I note that in both a) and b) above you never mention (duplicate,
filter, return) which was one of the earlier threads that was being
discussed. Is this option finally being laid to rest? I hope so.
ii) for option b) by combining duplicate entries and matched values
we actually have (search filter, duplicate, match filter, return) which
is more powerful than using the same filter in both instances. And
as Kurt pointed out, we can alternate the ordering of the duplication
and match filter (although this probably will not give different results
except for the case of when an empty set of attributes is returned.
With duplicate followed by match you could get identical entries
returned several times, containing an attribute with no values)
David
>
> I think a better alternative is to have the behavior be a) (which in
> my mind is simpler to implement), then allow use of the matched values
> control to produce the results of b). This way we are back to two
> separate controls that have non-overlapping specific functionality. If
> we agree to this proposal, I'll add appropriate text to the
> Interaction With Other Controls section.
>
> Jim
>
> >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 8/16/00 9:07:04 AM >>>
> At 03:04 PM 8/16/00 +0100, David Chadwick wrote:
>
> >> The issue should be what behavior do applications need and whether
> >> a) or b) (or both) or other controls fulfill the need. I think we
> >> should take a step back and discuss background and intended use
> >> information before choosing.
> >>
> >
> >Agreed. The usage scenario that I have heard is producing a paper
> >telephone directory, where you want one line for each telephone
> >number, so that people may be listed several times in the directory.
> >If the entry is only returned once with multiple values (as in the
> >standard Search), this does not produce the desired result. I cannot
> >remember another usage scenario being presented, but maybe others
> >can?
>
> My scenario is similar, I wanted to be able to search the
> directory for entries listing a specific area code and where
> the entry contained multiple values with this area code are
> returned as duplicated entries. I only want and desire any
> duplicates of containing a value within the desired area
> code. (One could call this "matched" duplicated entries).
>
> Kurt
>
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************