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