On 7 May 2019, at 23:56, Viktor Ashirov <vashirov(a)redhat.com>
wrote:
On Tue, May 7, 2019 at 2:09 PM William Brown <wbrown(a)suse.de> wrote:
>
>
>
>> On 7 May 2019, at 22:03, Viktor Ashirov <vashirov(a)redhat.com> wrote:
>>
>> On Mon, Apr 29, 2019 at 6:48 AM William Brown <wbrown(a)suse.de> wrote:
>>>
>>>
>>>
>>>> On 29 Apr 2019, at 12:33, Anuj Borah <aborah(a)redhat.com> 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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>>> 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@lists.fedoraproje...
>>
>>
>>
>> --
>> Viktor
>> _______________________________________________
>> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>> 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@lists.fedoraproje...
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproje...
--
Viktor
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs