Bug 989692 - Sorting with attributes in ldapsearch gives incorrect result
Summary: Sorting with attributes in ldapsearch gives incorrect result
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On: 918712
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 18:07 UTC by Noriko Hosoi
Modified: 2013-11-21 21:11 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-22.el6
Doc Type: Bug Fix
Doc Text:
Cause: When a server side sorting request is evaluated, the sort type (e.g., string, integer) was picked up only from the first attribute in the request and not reset even if the following attributes have the different sort type. Consequence: If the server receives a server side sorting request containing multiple sort attributes with the different sort types, it returns the incorrect result once it hits the different sort type from the first one. Fix: The server side sorting resets the sort type for each sort attribute in the request. Result: The server side sorting returns the correct sorted result when the server receives a request containing multiple sort attributes with the different sort types.
Clone Of: 918712
Environment:
Last Closed: 2013-11-21 21:11:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1653 normal SHIPPED_LIVE 389-ds-base bug fix update 2013-11-20 21:53:19 UTC

Description Noriko Hosoi 2013-07-29 18:07:14 UTC
+++ This bug was initially created as a clone of Bug #918712 +++

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/543

I have performed sorting in ldapsearch operation with all the combination of two attributes (sn, telephonenumber). I have made the 'sn' values of all the entries same and the 'telephonenumber' values different so that the sorting order for all the search results will be same. But the sorting order for the  search results are not same as expected. When I sort with "sn", "sn telephonenumber" and "telephonenumber sn" the ordering of the search results are same. The search results of "telephonenumber" sort is different from other results. At least the search results for sorting with "telephonenumber" and "telephonenumber sn"  should give similar results as all the entries have same 'sn' value.
Note: It is reproduced in 389 DS-1.2.15

Reproducer details:
----------------------------------------------------------------------
The data I have uploaded to the database is given below
dirsrv12@dirsrv12-VirtualBox:~$ cat data.ldif
dn: uid=scarter, ou=People, dc=asiapacific,dc=hpqcorp,dc=net
cn: Sam Carter
sn: Test sn
givenname: Sam
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: scarter
telephonenumber: 12

dn: uid=tmorris, ou=People, dc=asiapacific,dc=hpqcorp,dc=net
cn: Ted Morris
sn: Test sn
givenname: Ted
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: tmorris
telephonenumber: 1 3

dn: uid=kvaughan, ou=People, dc=asiapacific,dc=hpqcorp,dc=net
cn: Ken kvaughan
sn: Test sn
givenname: Kirsten
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: kvaughan
telephonenumber: 1   23

The sorting search results for all the combinations are given below
Sorting with sn
dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "sn" -x "(objectclass=inetorgperson)" sn telephonenumber
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel
# filter: (objectclass=inetorgperson)
# requesting: sn telephonenumber
#

# scarter, People, asiapacific.hpqcorp.net
dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 12

# tmorris, People, asiapacific.hpqcorp.net
dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1 3

# kvaughan, People, asiapacific.hpqcorp.net
dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1   23

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Sorting with telephonenumber
dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "telephonenumber" -x "(objectclass=inetorgperson)" sn telephonenumber
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel
# filter: (objectclass=inetorgperson)
# requesting: sn telephonenumber
#

# kvaughan, People, asiapacific.hpqcorp.net
dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1   23

# tmorris, People, asiapacific.hpqcorp.net
dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1 3

# scarter, People, asiapacific.hpqcorp.net
dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 12

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Sorting with telephonenumber sn
dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "telephonenumber sn" -x "(objectclass=inetorgperson)" sn telephonenumber
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel
# filter: (objectclass=inetorgperson)
# requesting: sn telephonenumber
#

# scarter, People, asiapacific.hpqcorp.net
dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 12

# tmorris, People, asiapacific.hpqcorp.net
dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1 3

# kvaughan, People, asiapacific.hpqcorp.net
dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1   23

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Sorting with sn telephonenumber
dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "sn telephonenumber" -x "(objectclass=inetorgperson)" sn telephonenumber
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel
# filter: (objectclass=inetorgperson)
# requesting: sn telephonenumber
#

# scarter, People, asiapacific.hpqcorp.net
dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 12

# tmorris, People, asiapacific.hpqcorp.net
dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1 3

# kvaughan, People, asiapacific.hpqcorp.net
dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net
sn: Test sn
telephonenumber: 1   23

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Comment 1 Noriko Hosoi 2013-07-31 20:03:39 UTC
Test case: clu/cluSearch:trac543

Comment 3 Amita Sharma 2013-09-20 10:04:34 UTC
In acceptance test report of RHEL65 ::

Bug trac 543 is fixed.
Search result /tet/testcases/DS/6.0/tet_tmp_dir//cluSearch_trac543.txt is identical to good result /tet/tet/../data/DS/6.0/clu/en//trac543.g_e.out.good
backend for dc=trac543,dc=com is trac543
modifying entry cn=USN,cn=plugins,cn=config

Hence Marking as VERIFIED.

Comment 4 errata-xmlrpc 2013-11-21 21:11:24 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1653.html


Note You need to log in before you can comment on or make changes to this bug.