Last Updated: 22 Nov 2021 14:24 by ADMIN
Created on: 07 Aug 2015 17:30
Category: PivotGrid
Type: Feature Request
Implement OData aggregation extensions (or helper feeds) as a dataSource for a PivotGrid
An OData feed that supports 'OData Extension for Data Aggregation Version 4.0'
can be queried for all of the information required to populate a PivotGrid
with rows and columns that are paged, sortable (including by different aggregates
of the measures), and filterable, and have all calculations performed on the server.

The pivot grid can be popualted using data obtained from a couple of requests
to a suitable feed -- or feeds.

Suppose we have an OData feed that we'd like to display in a pivot grid. Some of the 
columns in the feed will become dimensions, and some will become measures.
(We may display the same measure more than once, with different aggregates applied.)

In order to display the row/column headings for the pivotGrid we need to select the 
distinct values from the 'dimension' columns. The filtering provided by OData 
allows the row/column headings to be filtered, and even
paged (in both directions). Sorting is more difficult because we want to sort not only 
by the row/column heading values themselves, but also by (aggregates of) the measures.
However, that's a problem for the server side!

In order to populate the body of the table we need to calculate a load of aggregates
from the measure columns in the base dataset for the rows that correspond to visible
row/column headers. We can write a rather long OData $filter expression to obtain 
the required rows from the original OData feed, and then aggregate them.

All of this functionality is available in 'OData Extension for Data Aggregation Version 4.0'.
However, as an interim solution we may establish two 'helper' OData feeds associated
with the original feed: one for the dimensions for populating the row and column headers,
and one for the measures to populate the body of the table. The grid has already
established a convention for asking for aggregates computed on the server,
although this can be overridden using parameterMap anyway.