Additional Secondary Data View Properties

In addition to the virtual data view properties described in Additional Virtual Data View Properties, certain properties can be defined only on a secondary data view. These properties determine how data from the two views is aggregated and how requests to the data views are handled. The following sections describe these additional properties.

Join Rules

Join rules determine how an entry from a secondary data view relates to an entry from a primary data view. Join rules are not mandatory on a secondary data view. However, if no join rule is defined, the secondary data view is not queried during LDAP operations. Directory Proxy Server provides two types of join rules, DN join rules and filter join rules.

DN Join Rules

A DN join rule determines the DN of entries in the secondary data view. A DN join rule is configured on the secondary data view by using the dn-join-rule property. Only one DN join rule can be configured on a secondary data view. If a DN join rule is configured on a data view, a filter join rule cannot be configured on that data view.

A DN join rule has DN syntax and can take one of the following forms:

• The DN of the secondary entry is constructed from an attribute in the primary entry.

  For example, the following DN join rule stipulates that the DNs of entries in the secondary data view should include the cn from the primary data view, plus the ou=people suffix.

  cn=\${primary-data-view.cn},ou=people

  The DN must not contain the base DN of the secondary data view. In this sense, it is a relative DN.

• The DN of the secondary entry is the same as the DN of the primary entry.

  The syntax of such a join rule is as follows:

  \${primary-data-view.dn}

  In this case, the portion of the primary and the secondary DNs below the base DN are identical, although the full DNs may differ. Imagine, for example, that the primary data view has a base DN of o=primary and the secondary data views has a base DN of o=secondary. A join rule of \${primary-data-view.dn} implies that the DITs below the base DN are identical. So, the entry uid=1,o=secondary would be associated with uid=1,o=primary.

Filter Join Rules

A filter join rule defines the relationship between the primary and secondary data views. A filter join rule is configured on the secondary data view by using the filter-join-rule property. This rule indicates how an entry should be retrieved from the secondary data view based on something in the primary data view.

Only one filter join rule can be configured on a secondary data view. If a filter join rule is configured on a data view, a DN join rule cannot be configured on that data view. A filter join rule takes the form of a filter that is used to construct an attribute from one or more attributes from the primary data view.

For example, the following filter join rule stipulates that an entry be retrieved if the entry uid in the primary data view matches the entry uid in the secondary data view.

uid=\${primary.uid}

Handling of Shared Entries

The contains-shared-entries property determines what should be done if an entry in the secondary data view is used by more than one entry in the primary data view.

Imagine for example, that the primary data view contains a list of user entries and the secondary data view contains a list of department numbers. A single department number in the secondary data view might apply to more than one user in the primary data view. If a user is deleted from the primary data view, you do not necessarily want that user's department number to be deleted from the secondary data view.

The contains-shared-entries property is set on the secondary data view only. This property is set to TRUE by default. This means that deleting an entry in the primary data view will not result in the deletion of the shared entry in the secondary data view. Adding an entry to the primary data view will only add the entry to the secondary data view if it does not already exist.

Handling of Binds

The process-bind property specifies whether a bind can be performed on the secondary data view.

By default, primary data views allow binds and secondary data views do not. The process-bind property is not set by default. If this property is set to true on a secondary data view, binds are permitted on that data view.