Issue 3650 - multivalued sorting
Summary: multivalued sorting
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-11 17:17 UTC by b.hallinger@ergonaz.net
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description b.hallinger@ergonaz.net 2005-04-11 17:17:43 UTC
Full_Name: Benedikt Hallinger
Version: 
OS: Linux Debian (sarge)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.232.230.35)


Hello,
I am currently developing a php-application which uses LDAP.
There is a issue if you want to sort your searchresult by multivalued
attributes.

The php-development team has told me to get in contact with you, because they
only wrap around your ldap_sort_entries() function.

ldap_sort() is the php-function for ldap_sort_entries().

ldap_sort() works fine, but only if you sort by singlevalued
attributes.

I will post an example
dataset with two entries:

entry one:
sn=aaaa
id=1111
id=2222
id=3333

entry two:
sn=bbbb
id=6666
id=1000

Expected result:
----------------
If you sort by "id", the second entry should move to the first place,
which he doesnt, because only the first vlaues of "id" got compared.


Actual result:
--------------
entry one remains entry one, although id=6666 is greater than id=1111!
ldap_sort() overlooks, that there is an id which is smaller (id=1000).

I think the solution to this could be to tell ldap_sort() to search for
the biggest value in the multivalue attribute prior comparing with the
other entries.

Comment 1 ando@openldap.org 2005-04-12 16:15:53 UTC
The definition of sorting can be quite vague, since different criteria may
result from specific requirements; from ldap_sort(3):

NOTES
       The ldap_sort_entries() routine applies the comparison function to
each value of the attribute in the array as returned by a  call  to
       ldap_get_values(3),  until  a mismatch is found.  This works fine
for single-valued attributes, but may produce unexpected results
for
       multi-valued attributes.  When sorting by DN, the comparison
function is applied to an exploded version of the DN, without
types.  The
       return  values  for  all  of these functions are declared in the
<ldap.h> header file.  Some routines may dynamically allocate
memory.
       Callers are responsible for freeing such memory using the supplied
deallocation routines.

In short: the issue is known and documented.  In any case, since sorting
is performed at the client's side, you should write your own sorting
procedure if the default one doesn't fit your needs.

p.

PS: By the way, I think your report is putting a tombstone on the
discussion abour server side sorting as well.



-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

Comment 2 Kurt Zeilenga 2005-04-13 00:19:24 UTC
changed notes
changed state Open to Suspended
moved from Incoming to Software Enhancements
Comment 3 ando@openldap.org 2005-04-13 06:31:26 UTC
Please keep discusions on this ITS on the ITS list.

b.hallinger@ergonaz.net wrote:

> Does that mean, it will get never fixed?

Likely.  I don't really see an issue and, to be honest, I don't even 
understand why sorting is provided at all in the library: it has nothing 
to do with LDAP itself, and one should implement one's own sorting based 
on one's own requirements which may differ from client to client, as 
your problem is showing.  For instance: you may want  to sort in 
ascending or descending order.  If you are sorting for multivalued 
attrs, then if you want the best case, you'll want to consider only the 
lowest and the highest of the values, respectively; but if you want the 
worst case, you'd want the highest and the lowest, respectively.  
Furthermore, the client has no schema knowledge, so sorting 2 and 15 in 
ascending order yields 15, 2.  Maybe you'd prefer integer sorting in 
this case?

> And what is that about the tombstone you are talking about?
> (i don't know abaout the discussion about server side sorting, could 
> you please
> summarize it for me?)

It's a request for implementing server side sorting, something tht was 
described in RFC 2891 but poses a number of problems and is not likely 
to be implemented any time for a number of reasons, namely scalability 
and resource consumption, but also the difficulty (read impossibility) 
to define univoquely what "sorting" is: different clients may have 
different sorting criteria.  To read more, follow this thread:
<http://www.openldap.org/lists/openldap-software/200503/msg00803.html>

p.



    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

Comment 4 ando@openldap.org 2005-04-21 15:43:25 UTC
changed state Suspended to Closed
Comment 5 Howard Chu 2009-02-17 04:53:06 UTC
moved from Software Enhancements to Archive.Software Enhancements
Comment 6 OpenLDAP project 2014-08-01 21:06:58 UTC
close?