The composite profile repository supports all Repository Query Language (RQL) queries, even those referencing properties that come from different underlying repositories (as long as they are included in the composite view). For more information on RQL, see Repository Query Language in the Repository Guide.

Note that query performance depends to some extent on the complexity of the query—specifically, it depends on the number of comparisons across contributing views that a given query requires. For example, the following very common type of query generally provides a high level of efficiency:

This type of query compares properties in the composite view to constant values, and it joins those comparisons together via AND and OR statements. In this example, the composite repository stores firstName in the primary (GSA) view and phoneNumber in a contributing (LDAP) view. It is impossible, however, to return the appropriate set of composite users from a single query. Therefore, the composite view breaks the query down into sub-queries, each of which can be run against a single underlying repository. Then the results of the sub-queries are put together using the AND or OR rules, and a final result set is returned.

By contrast, the following example shows a type of query that may perform poorly:

Here, the dayPhone composite property comes from the primary (GSA) view and workPhone comes from a contributing (LDAP) view. For this query, the composite view must find the day phone number of every user in the primary view and compare it to the work phone number of its counterpart in the contributing view. If the values match, the user is added to the result set. Obviously, if the number of users is large, this search could take some time. It is recommended that you use this type of query sparingly to avoid an adverse effect on site performance.