You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 3, 2024. It is now read-only.
This is a feature proposal. Comments and ideas are encouraged.
PHP allows doing parallel searches. This could greatly enhance application's performance in situations where multiple search requests need to be issued.
Currently, the only way to perform parallel search is to gather the underlying ldap link resources with Ldap::getResource() and calling ldap_search() directly. This, however, breaks the purpose of having a testable ldap interface. As such, support for this feature should be added into the library.
A proposed API could look like this:
A new method is introduced, Ldap::parallelSearch() (or just Ldap::parallel()) with parameter signature identical to that of Ldap::ldapSearch()
Each call to this method would store the parameters in an array for later use (i.e. in a protected Ldap::$parallels property)
Once a call to Ldap::ldapSearch() is made (without arguments), a parallel search is executed with the params queued up in Ldap::$parallels and the results are returned in an array. The aforementioned protected property is emptied/reset.
Caveats
The above proposal would only work with doing parallel searches on the same ldap link, although PHP has no such limitation. This is not a big deal for Active Directory (you can always search the Global Catalog), but might be a problem for multi-domain setups for i.e. OpenLDAP users.
PHP does not allow retrieving specific sets of attributes for individual searches, i.e. you cannot tell PHP to retrieve only objectClass for first search and only objectCategory for the second search. I filed a PHP bug ages ago, but so far no progress has been made. In the past, I dealt with this by doing a union on the requested attributes, but this is somewhat unintuitive. A better approach would be to change the proposed API to not accept $attributes parameter in calls to Ldap::parallel() and only accept it once the Ldap::ldapSearch() method is called, i.e.:
// Example. Actual method signatures may vary.$ldap->parallel('DC=example,DC=com', 'objectClass=user', Ldap::SCOPE_SUBTREE);
$ldap->parallel('DC=example,DC=com', 'objectCategory=Person', Ldap::SCOPE_SUBTREE);
$ldap->ldapSearch(['objectClass', 'objectCategory', 'cn']);
The text was updated successfully, but these errors were encountered:
PHP allows doing parallel searches. This could greatly enhance application's performance in situations where multiple search requests need to be issued.
Currently, the only way to perform parallel search is to gather the underlying ldap link resources with
Ldap::getResource()
and callingldap_search()
directly. This, however, breaks the purpose of having a testable ldap interface. As such, support for this feature should be added into the library.A proposed API could look like this:
Ldap::parallelSearch()
(or justLdap::parallel()
) with parameter signature identical to that ofLdap::ldapSearch()
Ldap::$parallels
property)Ldap::ldapSearch()
is made (without arguments), a parallel search is executed with the params queued up inLdap::$parallels
and the results are returned in an array. The aforementioned protected property is emptied/reset.Caveats
The above proposal would only work with doing parallel searches on the same ldap link, although PHP has no such limitation. This is not a big deal for Active Directory (you can always search the Global Catalog), but might be a problem for multi-domain setups for i.e. OpenLDAP users.
PHP does not allow retrieving specific sets of attributes for individual searches, i.e. you cannot tell PHP to retrieve only
objectClass
for first search and onlyobjectCategory
for the second search. I filed a PHP bug ages ago, but so far no progress has been made. In the past, I dealt with this by doing a union on the requested attributes, but this is somewhat unintuitive. A better approach would be to change the proposed API to not accept$attributes
parameter in calls toLdap::parallel()
and only accept it once theLdap::ldapSearch()
method is called, i.e.:The text was updated successfully, but these errors were encountered: