> On 7 May 2019, at 22:03, Viktor Ashirov <vashirov@xxxxxxxxxx> wrote:
>
> On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbrown@xxxxxxx> wrote:
>>
>>
>>
>>> On 29 Apr 2019, at 12:33, Anuj Borah <aborah@xxxxxxxxxx> wrote:
>>>
>>> @William Brown
>>>
>>> Thanks for the tip!
>>>
>>> (Pdb) len(topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,"testUserAccountControl:1.2.840.113556.1.4.803:=8388608", ['attrlist=cn:sn:uid:testUserAccountControl']))
>>> 6
>>> (Pdb) len(Accounts(topo.standalone, DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)"))
>>> 6
>>>
>>> We cant not mix up ['attrlist=cn:sn:uid:testUserAccountControl'] with filter , like we do with search_s .
>>>
>>> (Pdb) len(Accounts(topo.standalone, DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608)", ['attrlist=cn:sn:uid:testUserAccountControl']))
>>> *** TypeError: filter() takes 2 positional arguments but 3 were given
>>> (Pdb) len(Accounts(topo.standalone, DEFAULT_SUFFIX).filter("(testUserAccountControl:1.2.840.113556.1.4.803:=8388608), ['attrlist=cn:sn:uid:testUserAccountControl']"))
>>> *** ldap.FILTER_ERROR: {'desc': 'Bad search filter', 'errno': 2, 'info': 'No such file or directory'}
>>>
>>> Again i have to use "re" module for the same .
>>>
>>>
>>
>> What are you trying to achieve?
> Test case is very simple: search for entries using different filters
> and request specific attributes.
But those entries have types and classes - you know what you are expecting to get.
> The problem that Anuj is facing is that filter() doesn't support
> attrlist. Moreover, _unsafe_raw_entry() doesn't return *all*
> attributes, it omits operational attributes (like nsRoleDN).
> IMHO, search_s is good enough here.
If you want to avoid any of the "magic" use DSLdapObjects(instance).filter() then because that doesn't prescribe any classes. But it does take a lot of the safety out of the library, and I still think that there is something missing in the approach here.
>>
>>
>> Sincerely,
>>
>> William Brown
>>
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>
> --
> Viktor
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
