Re: [ldap-sdk-discuss] LDAP SDK Java question
A Java-based LDAP API
Brought to you by:
dirmgr,
kennethleo
From: Neil A. W. <nei...@un...> - 2016-09-19 20:47:05
|
On 09/19/2016 12:21 PM, Kasim Doctor wrote: > Hi there, > > I am playing around with the LDAP Java SDK API to get a list of OUs from a > source directory. > > I searched everywhere but can't seem to find the answer to the following > question: > > When I get the list of OUs, what guarantee is there that the parent OUs are > returned before the child OUs are returned ? > > Please let me know if there is a spec somewhere for this > > Thanks, > Kasim There is no specification that requires a superior entry to be returned in search results before its subordinates. In fact, RFC 4511 section 4.5.2 states "The SearchResultEntry and SearchResultReference messages may come in any order.", so it would be legal for subordinate entries to be returned before their superiors. However, I expect that most LDAP servers do try to return superior entries before subordinates. I know that with the UnboundID Directory Server, we do guarantee that superior entries will be returned before any of their subordinates, with only a couple of exceptions (for example, searches including the server-side sort or persistent search request control). I can't speak definitively for other directory servers, but I expect that most servers do try to maintain this ordering under normal circumstances. If you're really paranoid about this, and if you expect that your search won't return a large number of entries, you can have the LDAP SDK sort the results for you, and you can specify that the sorting should order each entry first based on its position in the hierarchy and then based on its content. See the EntrySorter (https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/EntrySorter.html) class for more information. However, client-side sorting can only be done if you can hold all of the entries in memory, so you shouldn't do this if you think there might be a large number of matching entries. Neil |