This query selects all Message objects, but the
WHERE filter selects only those
Person objects whose
Department contains the term
sales. Hence, the
MIN metric finds the lowest (first alphabetic)
Office value whose sender is in the sales department.
When the WHERE function appears at the
beginning of the metric function, it filters
perspective objects, acting in conjunction with the query selection expression, if present. When used in this way, the
WHERE function must be followed by
.field where
field is the metric field name or link path. For example:
Since the COUNT function’s outer
WHERE filter is followed by
.*, the function counts objects. The
WHERE expression is AND-ed with the query expression
Office:also. Therefore, this query is similar (but not identical) to the following:
Because the scope of an outer WHERE function remains at the perspective table, multiple WHERE functions can be chained together to filter perspective objects. Example:
This query finds the smallest Message.Size value of all messages where (1) the message is tagged with
AfterHours, (2) at least one sender belongs to the
sales department, and (3) at least one internal recipient resides in the
aliso office.
This query performs two COUNT(*) functions: the first selects messages whose sender belong to
sales, the second those sender belong to
support. By definition, when a TOP or BOTTOM grouping field is used with a multi-metric query, the groups are generated from the sorted values of the
first metric function. Secondary metric functions follow the same grouping pattern so that the metric computations are correlated. A typical result for this query looks like this:
This allows the offices with the most email senders in sales to be directly compared to the number of email senders in
support for the same offices. If we executed two separate aggregate queries—one for each function—but with the same grouping parameter, we would get different, uncorrelated groups.