|
From: Konstantin C. <Kon...@da...> - 2000-10-11 13:20:42
|
Michael Ströder wrote:
> Konstantin Chuguev wrote:
> >
> > LDAP_BEGIN_ALLOW_THREADS( self );
> > result_type = ldap_result( self->ldap, msgid, all, tvp, &msg
> > );
> > result = ldap_result2error( self->ldap, msg, 0 );
> > LDAP_END_ALLOW_THREADS( self );
>
> Hmm, my slapd logs the occurence of the referral right after calling
> the search() method of the LDAP object. I guess the function
> ldap_result2error() should be called in l_ldap_search() either.
>
I think, this just means the LDAP server could answer immediately
(because of this low load and fast database). The result was probably
sent to the client and was caught by the LDAP library in some buffers.
You could issue other search requests and then start collecting results
of all the requests one by one with ldap_result() until LDAP library
buffers are empty. This is how I understand the asynchronous mode.
The l_ldap_result() python-ldap function is correct in the sense that it
just wraps the corresponding ldap_result() C function, no more no less.
Exception is raised only in case of LDAP or system error. But then msg
is converted to Python format (dictionary) and its C representation is
destroyed before exiting the function. It's not possible anymore to
provide data for ldap_result2error, even if there was a Python wrapper
for it. So the only solution I see is combining both C functions -
ldap_result() and ldap_result2error() in one wrapper.
No return data is lost because of Python exceptions.
I've attached a patch for l_ldap_result function.
Note that now the function raises exceptions both in case of an LDAP or
system error AND an unsuccessful LDAP operation result (including
LDAP_PARTIAL). It returns Py_None object if there was no result at all
(i.e. timeout has occured or no async requests were issued to the server
before the call).
--
* * Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW: http://www.dante.net
|