8.4. Using Views

Virtual directory tree views, or views, create a virtual directory hierarchy, so it is easy to navigate entries, without having to make sure those entries physically exist in any particular place. The view uses information about the entries to place them in the view hierarchy, similarly to members of a filtered role or a dynamic group. Views superimpose a DIT hierarchy over a set of entries, and to client applications, views appear as ordinary container hierarchies.

8.4.1. About Views

Views create a directory tree similar to the regular hierarchy, such as using organizational unit entries for subtrees, but views entries have an additional object class (nsview) and a filter attribute (nsviewfilter) that set up a filter for the entries which belong in that view. Once the view container entry is added, all of the entries that match the view filter instantly populate the view. The target entries only appear to exist in the view; their true location never changes. For example, a view may be created as ou=Location Views, and a filter is set for l=Mountain View. Every entry, such as cn=Jane Smith,l=Mountain View,ou=People,dc=example,dc=com, is immediately listed under the ou=Location Views entry, but the real cn=Jane Smith entry remains in the ou=People,dc=example,dc=com subtree.
A Directory Tree with a Virtual DIT View hierarchy

Figure 8.4. A Directory Tree with a Virtual DIT View hierarchy

Virtual DIT views behave like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned.

Note

There is a sample LDIF file with example views entries, Example-views.ldif, installed with Directory Server. This file is in the /usr/share/dirsrv/data/ directory. The sections in this chapter assume Example-views.ldif is imported to the server.
The Red Hat Directory Server Deployment Guide has more information on how to integrate views with the directory tree hierarchy.

8.4.2. Creating Views from the Command Line

  1. Use the ldapmodify utility to bind to the server and prepare it to add the new view entry to the configuration file.
  2. Assuming the view container ou=Location Views,dc=example,dc=com from the Example-views.ldif file is in the Directory Server, add the new views container entry, in this example, under the dc=example,dc=com root suffix. This entry must have the nsview object class and the nsViewFilter attribute. The nsViewFilter attribute sets the attribute-value which identifies entries that belong in the view.
    dn: ou=Mountain View,ou=Location Views,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: organizationalUnit
    objectClass: nsview
    ou: Mountain View
    nsViewFilter: l=Mountain View
    description: views categorized by location

8.4.3. Improving Views Performance

As Section 8.4.1, “About Views” describes, views are derived from search results based on a given filter. Part of the filter is the attribute defined in the nsViewFilter attribute; the rest of the filter is based on the entry hierarchy, looking for the entryid and parentid of the real entries included in the view.
(|(parentid=search_base_id)(entryid=search_base_id)
If any of the searched-for attributes — entryid, parentid, or the attribute set in nsViewFilter — are not indexed, then the views search becomes an unindexed search because the views operation searches the entire tree for matching entries.
To improve views performance, create equality indexes for entryid, parentid, and the attribute set in nsViewFilter.
Creating equality indexes is covered in Section 13.2, “Creating Standard Indexes”, and updating existing indexes to include new attributes is covered in Section 13.3, “Creating New Indexes to Existing Databases”.