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