> On 7 May 2019, at 23:56, Viktor Ashirov <vashirov@xxxxxxxxxx> wrote:
>
> On Tue, May 7, 2019 at 2:09 PM William Brown <wbrown@xxxxxxx> wrote:
>>
>>
>>
>>> 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.
> I have a problem with DSLdapObjects(instance).filter() is that it
> takes way more effort to write *test* code with a very little benefit.
> Consider this example: I need to fetch all regular attributes,
> operational attributes and entry state information from the server.
> With DSLdapObjects I had to do the following:
> (Pdb) _ = Accounts(topo.standalone, DEFAULT_SUFFIX)
> (Pdb) _._filterattrs=["*", "+", "nscpEntryWSI"]
> (Pdb) _.filter(F10)[0].get_all_attrs()
>
> get_all_attrs() doesn't return nscpEntryWSI at all, and, as a bonus,
> lowercases some of the attribute names.
>
> vs.
>
> (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> attrlist=["*", "+", "nscpEntryWSI"])
>
> Safety here is not a main concern, since it's a test code. In tests we
> need more than often to have a raw LDAP access without too much
> abstractions. Main concern is precision and certainty.
> Abstractions are good when they increase clarity and make things
> certain. In case of the very common search pattern above, DSLdapObject
> doesn't work really well. For me at least.
And that's fine, search_s can still work - the issue here is that Anuj has not articulated what he's trying to achieve, and has previously misunderstood the api :(. So honestly, I need to see this in a test case, with proper code structures to comment more.
The main reason to avoid search_s is that today in DirSrv it uses a really horrid hack to get Entry, which I have wanted to purge with fire for a long time - so the main reason to minimise it's use is to limit damage when I do eventually change that api.
>>
>>
>>>>
>>>>
>>>> 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
>
>
>
> --
> 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
