The following example shows how the user
and engineer
Repository Views are defined in an LDAP profile repository definition. The one-to-one correspondence between Repository Views and item descriptors in the XML template is enforced by making the item-descriptor
tag a sub-tag of view
. The view
tag also contains the search-root
tags, if any.
<view name="user" default="true"> <!-- item descriptor --> <item-descriptor name="user"> ... </item-descriptor> <!-- search roots --> <search-root dn="o=quincyfunds.com"/> </view> <view name="engineer"> <!-- item descriptor --> <item-descriptor name="engineer" parent="user"> ... </item-descriptor> <!-- search roots --> <search-root dn="ou=Engineering,o=quincyfunds.com" recursive="false" check-classes="true"/> </view>
In this example, the user
view spans all of o=quincyfunds.com
, including ou=Engineering,o=quincyfunds.com
, ou=Sales,o=quincyfunds.com,
and so on, whereas the engineer
view is restricted to ou=Engineering,o=quincyfunds.com
.
Note the default
attribute in the user
view specification, which designates user
as the default view name.
Search Root Attributes
There are a couple of optional attributes specified in the <search-root>
tag of the engineer
view above. The recursive
attribute specifies whether the tree branch should be searched recursively; the default is true
. You can set this to false
if you want to include only the root’s immediate children, or if you know for sure that lower levels of the branch do not contain any relevant entries. This might be used for optimization purposes).
Similarly, in some cases you might be able to set the check-classes
attribute to false
to optimize search performance. In the default case, with check-classes
set to true
, when a repository query is constructed, it is automatically augmented with the object class constraints, so items that do not satisfy the item descriptor are not returned by the search. For example, suppose you had a repository query (using the LDAP search filter syntax), such as:
(currentProject=Quincy)
If this query is applied to the ou=Engineering,o=quincyfunds.com
search root of the engineer
Repository View, the query becomes:
(&(currentProject=Quincy) (objectclass=top) (objectclass=person) (objectclass=organizationalPerson) (objectclass=inetorgPerson) (objectclass=dpsUser) (objectclass=engineeringPerson))
If the value of check-classes
is false
for the search root, however, the query is left as is, and no object class checking is performed. Obviously, this optimization should only be turned on if you are absolutely sure that the search root contains only entries that satisfy the item descriptor.