Closed Bug 11100 Opened 25 years ago Closed 20 years ago

Problems with LDAP sorting of entries

Categories

(Directory :: PerLDAP, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: leif, Assigned: leif)

Details

From: Jeff Clowser <jclowser@aerotek.com>

 ran into a problem where I needed to sort the entries I returned.  I wanted to
use ldap_sort_entries or
ldap_multisort_entries, but as I understand it right, you need to call the sort
between calling search_s and
get_first_entry.  Since both are done within perldap's search call, I didn't
have that option (unless I did
everything via API).  I looked at the code a little, and came up with a quick
hack based on sort, that I added
to Conn.pm - search_sort.  It's a quick hack, and I haven't tested it much, but
it does work against Netscape's
DS 4.01 (though if I understand right, ldap_(multi)sort_entries works on the
client side, so it's a function of
the SDK, not the server(?))

I should probably parse some errors and such, but I haven't gotten that familiar
with perldap's internals yet,
and like I said, this was a quick hack.  I figured it won't hurt too much - if I
get an error, I think the worst is
that it leaves things unsorted... Figured I'd send it to you, in case you want
to look it over, add it to perldap,
toss it out, whatever before passing it out publicly and causing problems...

It uses multisort, so can sort multiple attributes, which are passed as an array
reference parameter just
before the list of attributes to return.  If I spent more time on it, I might
have passed both arrays as
references, but I kept getting segmentation faults when I did that (even if I
corrected for that in the
search_sort routine), so I just left it as is...

Usage:
@sortattr=("sn","givenname");
@attr=("cn","sn","givenname");
$filter="(sn=clo*)";
$entry = $conn->search_sort($base,$scope,$filter,0,\@sortattr,@attr);


Oh, yeah - it's based on PerLDAP 1.2.1, in case anything changed in 1.2.2.


sub search_sort
{
####Added $sortattr#####################
  my ($self, $basedn, $scope, $filter, $attrsonly, $sortattr, @attrs) = @_;
  my $resv, $entry;
  my $res = \$resv;

  $scope = Mozilla::LDAP::Utils::str2Scope($scope);
  $filter = "(objectclass=*)" if ($filter =~ /^ALL$/i);

  if (defined($self->{"ldres"}))
    {
      ldap_msgfree($self->{"ldres"});
      undef $self->{"ldres"};
    }
  if (ldap_is_ldap_url($filter))
    {
      if (! ldap_url_search_s($self->{"ld"}, $filter, $attrsonly, $res))
        {
          $self->{"ldres"} = $res;
######### Added Code here for sort##########################################
          if ($sortattr){
            ldap_multisort_entries($self->{"ld"},$res,$sortattr);
          }
############################################################################
          $self->{"ldfe"} = 1;
          $entry = $self->nextEntry();
        }
    }
  else
    {
      if (! ldap_search_s($self->{"ld"}, $basedn, $scope, $filter, \@attrs,
                          $attrsonly, $res))
        {
# save result here - we want the result of the search, not the sort.  If the
sort fails,
# we just get unsorted results(?), but if the search fails, we want to know
about it.
          $self->{"ldres"} = $res;
######### Added Code here for sort##########################################
          if ($sortattr){
            ldap_multisort_entries($self->{"ld"},$res,$sortattr);
          }
############################################################################

          $self->{"ldfe"} = 1;
          $entry = $self->nextEntry();
        }
    }

  return $entry;
}
Status: NEW → ASSIGNED
This bug has not been touched for more than nine months. In most cases, that 
means it has "slipped through the net". Please could the owner take a moment to 
add a comment to the bug with current status, and/or close it.

Thank you :-)

Gerv
I'll look into adding a "sort" mechanism to the search() functions, now that we
have the hash-based argument passings. If I can get it to work, it'd only be
usable via the new argument style.
Priority: P3 → P2
Ok, this is now "fixed" on the dev branch (soon to be v1.5). The syntax is
slightly different than proposed here, to avoid having to add yet another
method. To use this new feature, do

$entry = $conn->search({ base => "o=ogre.com",
                         scope => "sub",
                         filter => "(objectclass=*)",
                         sortattrs => ["cn"] });


or some such. The documentation for this is not yet updated, but it will be.
This is in line with the changes I've made to support a hash of arguments for
all methods that takes more than one argument. It's also backward compatible
with previous versions of PerLDAP, but then the new sorting feature is not
available.

Thanks for the suggestion!
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.