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.
