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

Re: VLV indices and multi-value attributes



John Merrells wrote

>> We're hearing similar requests.  If the SSS request control looked like this, we could have it both ways:
>>
>>      SortKeyList ::= SEQUENCE OF SEQUENCE {
>>                 attributeType   AttributeDescription,
>>                 orderingRule    [0] MatchingRuleId OPTIONAL,
>>                 reverseOrder    [1] BOOLEAN DEFAULT FALSE
>>                 allValues          [2] BOOLEAN DEFAULT FALSE }
>>
>> where allValues specifies whether or not all attribute values are used (which would result in possible duplicates).
>
>This is at odds with the definition of the sort control, which is supposed to define
>the ordering of the result set.  The search (base,scope,filter) tuple selects the set
of entries. Ignoring base and scope, a filter such as (sn=*) selects all the entries
>that have an 'sn' attribute.  What's needed is a filter that will return an entry for
>each and every 'sn' attribute value. Perhaps.... (sn#).

Good point, so the heart of the problem is in search but the symptom doesn't manifest itself until we try to sort.  Though it's hard to imagine other scenarios where one would ask search to return duplicate entries, the ability shouldn't be limited to sorting.

I like the idea of focusing on search to solve this problem but I think that using the search filter would meet with resistance.  The reason being, search filter is (so far), used solely to specify matching conditions, rather than to change the behavior of search.  What's needed here seems more like behavior modification than matching.

I'm beginning to think that the proper way to do this is through its own control (I'm eating my words Tim, sorry for the resistance to that idea). The control would simply contain a list of attribute types specifying that search return separate entries for each value in that attribute (if present). It would also have to either state policy or allow specification of what should be contained in the attributes of the returned entries. I imagine each entry would contain single values in those attributes that are specified in this control (otherwise, knowing *which* value this entry represents would be a bear).

Does this sound reasonable?

Jim