Database Reference
In-Depth Information
GROUP BY application_id
ORDER BY mem_per_pkg DESC
The usage of the clause is self-explanatory. The key point to note is that the
aggregate functions are scoped to the field being omitted. If you replaced
running
with
RECORD
, then
COUNT(running.package)
would have
counted the total packages across all applications in the record.
Say you want to ignore a specific application in the calculation of memory
usage. You could do this quite simply by modifying the scope.
OMIT running.package IF running.package =
'com.google.android.gms'
If instead, you want to exclude entire applications that use this package you
need to modify the scope of the
OMIT IF
clause. The issue is that you want
to omit the entire
running
element but that requires you only refer to the
running.package
field inside an aggregate function. Here is one simple
way to achieve this result.
OMIT running IF SOME(running.package =
'com.google.android.gms')
SOME(<
condition
>)
acts as a disjunction, evaluating to true if any of its
inputs are true. Similarly,
EVERY
can be used as a conjunction that requires
all its inputs to evaluate to true. These simple aggregation functions make
the
OMIT IF
clause useful in a variety of queries involving repeated fields.
FLATTEN
As long as a query does not involve
independently
repeating fields, the
semantics of querying repeated fields are faithful to inner join semantics as
described earlier. When there are multiple independently repeating fields,
the rules are more complicated. Before discussing how such fields can be
mixed, you first need to understand what it means to be independently
repeating. Intuitively, two fields repeat independently if there is no
correspondence between the elements of one field and the elements of the
other field. More precisely, a field may repeat because it is itself repeated
or any record in the path to the field is repeated; two fields repeat
independently if the set of repeated fields in the path to either field is not a
