Re: VLV indices and multi-value attributes

[Ed Reed <ED_REED@novell.com>]

In fact, if you simply follow the canonical syntax for relational SELECT operations, you see

SELECT columns (attributes, in LDAP)
FROM tables (classes in LDAP)
WHERE selection criteria (search filter in LDAP)
ORDER BY results ordering criteria (your proposed sort control in LDAP)

I agree that you don't want to put sort order information into the search filter.  Ordering of search results
naturally seems to involve another criteria, separate from the selection criteria.

Of course, extending the FROM clause to support more than one class, and extending the WHERE clause 
to allow equi-joins are the subject of a proposal to the ITU for X.500, if I recall...

The notion of a sort control which could then be added to LIST and SEARCH operations (when and if
LIST is separated from SEARCH in LDAP) makes sense to me.

Question - is the reverseOrder field intended to mean DESCENDING (false, or true)?  

Ed

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320

>>> "Jim Sermersheim" <JIMSE@novell.com> 10/16/1998 16:31:34 >>>
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