[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: multiple attribute list need

The need is to get back pairs of full name/email address as opposed to a
list of full names and a list of email addresses and then have to manually
join them hoping they are in the same order.  A dynamic list cannot return
multiple values for 'displayName' and it does not return the data in pairs.
In the example provided we used 'departmentNumber' to create a group of
people and are returning their full name and email address.  Initially we
would create one such group for each of the departments we have in the
organization.  Going forward we would create additional groups based on
other criteria.  So, the need is to return pairs of fullname/email address
data when LDAP is queried for a particular group/list while keeping the
application unaware of the different criteria set up in LDAP to group the
people together.


-----Original Message-----
From: Pierangelo Masarati [mailto:ando@sys-net.it] 
Sent: Monday, August 13, 2007 12:09 PM
To: Paul Ghosh
Cc: openldap-software@openldap.org
Subject: Re: multiple attribute list need

Paul Ghosh wrote:
> There is an application that needs to display multiple lists of people
with
> their email address.  The number of lists and the content of the lists we
> would like to leave configurable in LDAP.  So, we set up a few dynamic
lists
> in LDAP, put them into a 'groupOfUniqueNames' object which the application
> retrieved, and then in turn queried the dynamic lists to obtain the
contents
> of the lists.  We ran into three challenges: First, since dynamic lists
> follow the schema definition rules it could not return multiple values for
> the attribute 'displayName' so we configured it for 'givenName' instead.
> Second, it returned the results grouped by email address and names instead
> of pairs of data so we walked through all the email addresses and then the
> names while confirming the counts were the same and assuming that they
were
> in the same order.  Third, if an email address or name was missing then
the
> manual pairing of data would be incorrect so we put in a filter that
ensures
> only members with both pieces of data were included.  Ideally we would
like
> to retrieve pairs of full names and email addresses.  The following does
> provide the information to us in the preferred format:
> 
> ldapsearch -a never -h xxx.xxx.xxx.xxx -b "ou=people,dc=example,dc=com" -x
> (&(&(departmentNumber=other)(mail=*))(displayName=*))" displayName mail
> 
> # extended LDIF
> #
> # LDAPv3
> # base <ou=people,dc=example,dc=com> with scope subtree
> # filter: (&(&(departmentNumber=other)(mail=*))(displayName=*))
> # requesting: displayName mail
> #
> 
> # root, people, example.com
> dn: uid=root,ou=people,dc=example,dc=com
> mail: root@example.com
> displayName: root
> 
> # nobody, people, example.com
> dn: uid=nobody,ou=people,dc=example,dc=com
> displayName: nobody
> mail: nobody@example.com
> 
> # jsmith, people, example.com
> dn: uid=jsmith,ou=people,dc=example,dc=com
> mail: jsmith@example.com
> displayName: John Smith
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 4
> # numEntries: 3
> 
> An equivalent is the following which is set up as a 'memberURL' attribute
of
> a 'groupOfURLs' object with the exception of 'givenName' instead of
> 'displayName' because of dynamic list adherence to schema definitions:
>
ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber
> =other)(mail=*))(givenName=*))
> 
> ldapsearch -a never -h xxx.xxx.xxx.xxx -b
> "cn=other,ou=lists,dc=example,dc=com" -x
> 
> # extended LDIF
> #
> # LDAPv3
> # base <cn=other,ou=lists,dc=example,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> 
> # other, lists, example.com
> dn: cn=other,ou=lists,dc=example,dc=com
> cn: other
> objectClass: groupOfURLs
> objectClass: top
> memberURL:
>
ldap:///ou=people,dc=example,dc=com?mail,givenName?sub?(&(&(departmentNumber
> =other)(mail=*))(givenName=*))
> mail: root@example.com
> mail: nobody@example.com
> mail: jsmith@example.com
> givenName: root
> givenName: nobody
> givenName: John Smith
> member: uid=root,ou=people,dc=example,dc=com
> member: uid=nobody,ou=people,dc=example,dc=com
> member: uid=jsmith,ou=people,dc=example,dc=com
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> Is there a way to accomplish what the regular search returns using
openldap
> features?


what the regular search returns seems to be the result of a regular
search.  It is not clear what special feature should be used to
accomplish it.  Can you restate in a clearer manner what you expect?

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------