@William Brown <wbr...@suse.de>
Thank you for the clarification.
Regards
Anuj Borah
On Thu, May 9, 2019 at 8:57 AM William Brown <wbr...@suse.de> wrote:
>
>
> > On 9 May 2019, at 12:47, Anuj Borah <abo...@redhat.com> wrote:
> >
> > @William Brown
> >
> > I am attaching the main script where i am facing the problem .
> >
> > F4 gives me the following :
> >
> > With search_s:
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE, F4)
> > [dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: uid=trigden,ou=People,dc=example,dc=com
> > objectClass: top
> > objectClass: account
> > objectClass: posixaccount
> > objectClass: inetOrgPerson
> > objectClass: organizationalPerson
> > objectClass: nsMemberOf
> > objectClass: nsAccount
> > objectClass: person
> > ou: Product Development
> > ou: People
> > roomNumber: 2511
> > sn: Hall
> > telephoneNumber: +1 408 555 6067
> > uid: bhall
> > uidNumber: 1000
> > userPassword:
> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
> >
> > ]
> >
> > With filter:
> >
> > (Pdb) Accounts(topo.standalone, DEFAULT_SUFFIX).filter(F4)[0].dn
> > 'uid=bhall,ou=People,dc=example,dc=com'
> > (Pdb) Accounts(topo.standalone,
> DEFAULT_SUFFIX).filter(F4)[0]._unsafe_raw_entry()
> > dn: uid=bhall,ou=People,dc=example,dc=com
> > cn: Benjamin Hall
> > gidNumber: 2000
> > givenName: Benjamin
> > homeDirectory: /home/bhall
> > l: sunnyvale
> > mail: bh...@anuj.com
> > manager: uid=trigden,ou=People,dc=example,dc=com
> > objectClass: top
> > objectClass: account
> > objectClass: posixaccount
> > objectClass: inetOrgPerson
> > objectClass: organizationalPerson
> > objectClass: nsMemberOf
> > objectClass: nsAccount
> > objectClass: person
> > ou: Product Development
> > ou: People
> > roomNumber: 2511
> > sn: Hall
> > telephoneNumber: +1 408 555 6067
> > uid: bhall
> > uidNumber: 1000
> > userPassword:
> {PBKDF2_SHA256}AAAIAAlpB8Yaw03XDVfXkH++eiCaugb3D660gbb6xBE3dkSCXOiCVqvM80dTPhPuSBISkY8IWJZgZXXoDt54brqRweEpqZ4YPrMTtqBAd/2kCsX+ZRM9phJLZFd9k7bIAM3joCnxVPFwyR1ETDSHkes0RSql7Isi+oKb8dloC+m5vzj1NG1M/o0TxdICTMxIBvuln+BdANOS9waGyqJgZfZBnQfw2t3lHOKXFxiduaWSZJvwVV8JtYkHt/ofdmqKItayc00eG6EM44qPS19XZa+3drTADPkL7HNAVhMHg1Y8iIWIXKvlZ7WJ1V/ySrHL6SU6XzcXtMNjBT/qi+GCHpu2Bc+Ka2C0iUZwY5ZiJ7YUANa3UYxh6oIVUgKNVmX+4CkJczJLcEgoI43zFCFnFsjtNHYwflPuIPFtwaXvgeBojItZ
> >
> > Now consider the following condition ,
> >
> > (Pdb) topo.standalone.search_s(DEFAULT_SUFFIX, ldap.SCOPE_SUBTREE,
> F4,['modifiersName','modifyTimestamp'])
> > [dn: uid=bhall,ou=People,dc=example,dc=com
> > modifiersName: cn=directory manager
> > modifyTimestamp: 20190509030743Z
> >
> > ]
> >
> > Problem is :
> > modifiersName and modifyTimestamp can never get with filter .
>
>
> This is not the fault of the filter, but the fault of how you are treating
> these objects. Filter tells you *what entries to find* not what attributes
> to get from them. To get specific attributes you have to interact with the
> results of the filter search.
>
> I have formerly mentioned you can assign the results of searches such as:
>
> bhall_account = Accounts(...).filter(F4)[0]
>
> bhall_account is now an Instance of the Account object, which itself is
> DSLdapObject. Now you have the entry, you can access attributes of it.
>
> values =
> bhall_account.get_attrs_vals_utf8(['modifiersName','modifyTimestamp'])
> print(values)
>
> Should be:
>
> {
> "modifiersName": '...',
> "modifyTimestamp": '...',
> }
>
> I don't know why you still are afraid to assign results from the searches.
> Fundamentally: DSLdapObjects (and it's subclasses) is the SET of all
> possible entries, and the gateway to searching. It returns instances of
> DSLdapObject, that allow direct inspection and manipulation of that
> data from the entry. I am worried that there is a still a deep
> misunderstanding of the API and how to use it, which is causing these
> problems (and odd accusations ...) and I don't understand how to explain it
> or help you to get past this barrier because this topic has been circled
> and discussed for months. How can I help you to understand how to use this
> properly and correctly?
>
>
> PS: There is a reason that function has the word "unsafe" in it, so please
> don't use things marked unsafe in tests or code .... :(
>
>
> —
> 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
