PingDirectory

Virtual attribute limitations

This section describes the limitations of virtual attributes, such as performance, indexing, and consistency limitations.

Performance limitations

The performance impact of virtual attribute generation is limited by computing these values only if they are returned to the client. However, performance can still be impacted because of other factors. Virtual attributes might be included or excluded based on a range of criteria and the evaluation of this criteria (for example, based on group membership) can impact performance.

Indexing limitations

You cannot index the values of a virtual attribute because the values can change from one invocation to the next.

Some virtual attributes implement support for an index-like functionality by offering logic that can quickly identify entries with specified virtual attribute values. These include the following:

  • When mirroring values from another attribute in the same entry, and when that source attribute type is indexed, the mirror virtual attribute provider can use an internal search to identify matching entries.

  • The entryDN virtual attribute provider retrieves the entry with the specified distinguished name (DN).

  • The isMemberOf virtual attribute provider uses the server’s group manager to identify the members of a targeted group.

This is not an option for all types of virtual attributes.

Index-like functionality is not available for the following virtual attribute types:

  • User-defined virtual attributes that have a static value

  • Constructed virtual attributes whose values are constructed from multiple other attributes in the same entry

  • Mirror virtual attributes whose values come from other entries

  • Any custom virtual attribute types implemented using the Server SDK

If you want to have a mix of standard and virtual values for the same attribute type, whether in the same entry or in different entries, there is not a good solution. If you define an index for that attribute type, it only includes entries with standard values and entries with virtual values are overlooked. If there is no index but the virtual attribute provider supports some search functionality, only entries with virtual values are matched and entries with only standard values are excluded.

Unexpected behavior for write operations

A significant issue with virtual attributes is that they can result in unexpected behaviors when targeted by write operations.

These unexpected behaviors include the following:

  • Attempting to delete a virtual value fails with a no such attribute result.

  • If the virtual attribute provider is configured with a conflict-behavior of real-overrides-virtual, then attempting to add a value to an entry that only has virtual values causes the virtual values to disappear.

  • If the virtual attribute provider is configured with a conflict-behavior of real-overrides-virtual, then attempting to remove all real values of an entry causes the virtual values to appear.

  • If the virtual attribute provider is configured with aconflict-behavior of virtual-overrides-real, then attempting to add new values or replace the set of existing values yields a success result, but the operation has no visible effect on the entry.

  • If the virtual attribute provider is configured with a conflict-behavior of merge-real-and-virtual, then attempting to replace the set of values for an entry yields a success result, but only the real values are replaced and the virtual values remain.

There is currently no method to prevent attempts to write to attributes with virtual values. The NO-USER-MODIFICATION constraint in attribute type definitions is honored, but this constraint only applies to operational attribute types. This is not an acceptable limitation in many cases. Access control restrictions could work for many clients, but do not have any effect for requesters with the bypass-acl privilege.