> On 7 May 2019, at 23:56, Viktor Ashirov <[email protected]> wrote: > > On Tue, May 7, 2019 at 2:09 PM William Brown <[email protected]> wrote: >> >> >> >>> On 7 May 2019, at 22:03, Viktor Ashirov <[email protected]> wrote: >>> >>> On Mon, Apr 29, 2019 at 6:48 AM William Brown <[email protected]> wrote: >>>> >>>> >>>> >>>>> On 29 Apr 2019, at 12:33, Anuj Borah <[email protected]> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> 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/[email protected] >>> >>> >>> >>> -- >>> Viktor >>> _______________________________________________ >>> 389-devel mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected] >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> _______________________________________________ >> 389-devel mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] > > > > -- > Viktor > _______________________________________________ > 389-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
