HP-UX Directory Server 8.1 deployment guide

It may be desirable to limit the type of entry that the view should contain. For example, to limit
this hierarchy to contain only people entries, add an nsfilter attribute to ou=Location
Views, dc=example, dc=com with the filter value
(objectclass=organizationalperson).
Each view with a filter restricts the content of all descendant views, while descendant views with
filters also restrict their ancestor's contents. For example, creating the top view ou=Location
Views first together with the new filter mentioned above would create a view with all entries
with the organization object class. When the descendant views are added that further restrict
entries, the entries that now appear in the descendant views are removed from the ancestor
views. This demonstrates how virtual DIT views mimic the behavior of traditional DITs.
Although virtual DIT views mimic the behavior of traditional DITs, views can do something that
traditional DITs cannot: entries can appear in more than one location. For example, to associate
Entry B with both Mountain View and Sunnyvale (see Figure 4-12 “A DIT with a virtual
DIT view hierarchy”), add the Sunnyvale value to the location attribute, and the entry appears
in both views.
4.4.4 Views and other directory features
Both class of service and roles in Directory Server support views; see “Grouping directory entries”.
When adding a class of service or a role under a view hierarchy, the entries that are both logically
and actually contained in the view are considered within scope. This means that roles and class
of service can be applied using a virtual DIT view, but the effects of that application can be seen
even when querying the flat namespace.
For information on using these features, refer to "Advanced Entry Management," in the HP-UX
Directory Server administrator guide.
The use of views requires a slightly different approach to access control. Because there is currently
no explicit support for ACLs in views, create role-based ACLs at the view parent and add the
roles to the appropriate parts of the view hierarchy. In this way, take advantage of the
organizational property of the hierarchy.
If the base of a search is a view and the scope of the search is not a base, then the search is a
views-based search. Otherwise, it is a conventional search.
For example, performing a search with a base of dc=example, dc=com does not return any
entries from the virtual search space are returned; in fact, no virtual-search-space search is
performed. Views processing occurs only if the search base is ou=Location Views. This way,
views ensure that the search does not result in entries from both locations. (If it were a
conventional DIT, entries from both locations are returned.)
4.4.5 Effects of virtual views on performance
The performance of views-based hierarchies depends on the construction of the hierarchy itself
and the number of entries in the DIT. In general, there may be a marginal change in performance
(within a few percentage points of equivalent searches on a conventional DIT) if virtual DIT
views are enabled in the directory service. If a search does not invoke a view, then there is no
performance impact. Test the virtual DIT views against expected search patterns and loads before
deployment.
We also recommend that the attributes used in view filters be indexed if the views are to be used
as general-purpose navigation tools in the organization. Further, when a sub-filter used by views
matches a configured virtual list view index, that index is used in views evaluation.
There is no need to tune any other part of the directory specifically for views.
4.4.6 Compatibility with existing applications
Virtual DIT views are designed to mimic conventional DITs to a high degree. The existence of
views should be transparent to most applications; there should be no indication that they are
4.4 Virtual directory information tree views 55