Sun Directory Server Enterprise Edition 7.0 Reference

Join Data Views

A join data view is an aggregation of multiple data views. The current release of Directory Proxy Server supports the aggregation of two data views into one join data view.

A join data view is created by specifying its name and the two existing data views that will be aggregated. One of these existing data views is considered the primary data view, and the other the secondary data view. Before you create the join data view, you need to configure the rules on the secondary data view that determine how the data is aggregated.

The following figure shows the aggregation of a primary and secondary data view to form one join data view.

Figure shows aggregation of two join source data views.

Primary and Secondary Data Views

The hierarchical organization of the sources for a join data view enables Directory Proxy Server to make default decisions where the data from the primary and secondary data views do not match.

The primary data view controls the existence of entries in the join data view. The secondary data view provides supplementary data for this list of entries. In other words, if an entry exists in the secondary data view but not in the primary data view, it does not appear in the join data view.

The primary data view is the authoritative source by default. When an attribute is present on both source data views but has a different value on each, a multi-valued attribute is returned. This behavior is configurable, however. For example, you can choose to accept only the value in the primary data view, or only the value in the secondary data view.

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:

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.

How Directory Proxy Server Handles Read and Write Operations to Join Data Views

If an attribute exists on both the primary and secondary data view, the attribute values are merged by the join data view. For read operations, this implies that a multi-valued attribute is returned, with the values from both data views. For write operations, the proxy queries both data views and determines where to write the value based on the content of the write operation.

If one backend data source fails during an add operation Directory Proxy Server performs an automatic rollback. The roll back takes the form of a delete operation on the data source that did not fail. This ensures the consistency of the data between the two data sources. If a roll back cannot be performed, an error is logged and an optional administrative alert is raised. Automatic roll back is on by default. You can configure automatic roll back by setting the revertAddOnFailure attribute to off (directly in cn=config).

If one backend data source fails during a delete operation, no roll back is performed. An error is logged and an optional administrative alert is raised.

Virtual Data Transformations on Join Data Views

Virtual data transformations are described in Virtual Data Transformations. The syntax of a transformation parameter differs slightly if the data transformation is defined on a join data view. Because an attribute can be obtained from more than one data view, variables that define the attribute content must be fully qualified. That is, the source attribute value must include the name of the data view from which the attribute is taken.

For example, the following parameter creates an attribute from existing attributes in both the primary and secondary data views:

\${primaryDataView.firstName}.\${secondaryDataView.lastName}@\${primaryDataView.domainName}

The firstName and domainName attributes are taken from the primary data view, and the lastName attribute is taken from the secondary data view.