[python-ldap] Supporting syncrepl (and fixing LDAPObject.results{, 2, 3, 4})

[Stephen J. Butler]

Apologies, my memory is fuzzy on this...

Way back in 2015 I was working with the result2() function and trying to
handle a case where I'd performed multiple LDAP operations at once (in this
case, I'd start a search over multiple bases at the same time and use the
result2() function to process them as they came in). My issue at the time
was that I could catch the LDAPError thrown from result2(), but the error
object did not contain the msgid that caused the error. So I didn't know if
it was one of my parallel searches that errored, or some extended operation
with an immediate result, or something else in the code. I submitted a
patch but there was some discussion and IDK that LDAPError ever got a msgid
field.

As I'm reading your proposal it sounds like this new result handling would
not throw an LDAPError for non-zero and let the calling code handle it. If
I'd had that back in 2015 I think that would have solved my issue. So 👍



On Tue, Mar 15, 2022 at 7:10 AM Ondřej Kuzník <ondra at mistotebe.net> wrote:

> Hi all,
> this has been on my list for a while and definitely needs fixing
> for 4.0. The way we parse results is broken, we cannot process
> intermediate responses properly and the results are n-tuples where n
> often depends on the arguments passed to .result4(). Also the way
> LDAPmessage_to_python works, we lose the order messages actually came
> in, that's a no-no for syncrepl at the very least. And .result() callers
> shouldn't get an exception when a non-zero result message is received,
> losing all other messages in the process forever.
>
> This needs work on all levels of the module:
> - C code needs to expose a new results interface that returns everything
>   in a common interface with common fields like result, message,
>   references, OID, controls etc. where appropriate.
> - by the time they are returned from the Python side, each response should
>   be an instance of LDAPMessage subclass as appropriate with controls,
>   intermediate and extended messages fully decoded if a decoder is
>   available. It will be possible to check the result code and raise an
>   appropriate exception as usual for each message derived from
>   LDAPResult.
>
> This is a stepping stone towards a similar overhaul of the request API,
> removing some of the distinction between the _s and non-_s variants as
> well as resiter eventually enabling asyncio compatible operation (see
> my asyncio wrapper[0] for an example how the API could look like).
> Of course, it will be fun to make sure we don't break any backwards
> compatibility in the 3.x interface for others.
>
> Comments on the design and volunteers to help with this are welcome.
>
> [0].
> https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py
>
> Regards,
>
> --
> Ondřej Kuzník
> Senior Software Engineer
> Symas Corporation                       http://www.symas.com
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20220316/ce85c0cb/attachment.html>