Composed attribute support provides an alternative to a specific set of use cases, and these use cases may also be addressed by virtual attribute support. While the composed attribute solution may provide improvements in performance, searchability, and write behavior, it also has a number of limitations relative to the virtual attribute subsystem. Some of those limitations include:
  • When creating a composed attribute plugin in the server, manual action is required to populate composed values in existing entries. When enabling a virtual attribute, the attribute is immediately available to clients.
  • When removing a virtual attribute from the server, values that would have been generated for the attribute will no longer be present. When removing or disabling a composed attribute plugin, composed values that had already been generated will remain.
  • Virtual attributes can be configured so that the values are only generated under certain conditions (for example, only for certain clients), and so that different values may be generated for different clients. Composed attributes will be the same for all clients (although access controls can be used to restrict which clients have access to them).
  • Virtual attributes do not require any additional storage or memory usage. Composed attributes actually exist in the database and therefore require additional disk space and memory for caching.
  • The composed attribute plugin can only generate values from a combination of static text and values from other attributes in the same entry. Virtual attributes can use a much wider range of logic when generating values, including custom logic implemented using the Server SDK.