Aggregating/Summarizing a Model's Data

[Phlucious]

Possible duplicate: http://www.qtcentre.org/threads/14930-Aggregating-a-model-s-data

I have a QStandardItemModel of items where each row corresponds to a single object and each column corresponds to a property of that object. Here's an example using a student ID roster:



ID Gender Grade GPA
5 Male 12 3.8
4 Female 11 3.9
8 Female 12 3.5
19 Male 9 2.1
My end goal is to let the user select one of the column names from a drop-down and have a second table display an aggregate of the values. For example, if the user selected Grade from the list, the second table would display the average GPA for each grade as follows:



ID Gender Grade GPA
12 3.65
11 3.9
9 2.1

Or similarly by Gender:



ID Gender Grade GPA
Male 2.95
Female 3.70


Is there anything in Qt that performs that functionality? QSortFilterProxyModel seems to come close in terms of functionality, but as far as I can tell it only culls and sorts items, not summarizes them.

[wysota]

You have to provide your own QAbstractProxyModel implementation that performs such calculations. For performance reasons you probably want to calculate aggregates on request and cache them in the proxy model instead of recalculating them each time someone asks for data.

[Phlucious]

Thanks for the reply! I like the idea of a proxy model, but I don't understand the implementation. Wouldn't the proxy model have to create its own items to display the aggregates that are related to the original model items? My current understanding of proxy models is that they only filter/sort/re-format existing items.

[wysota]

Wouldn't the proxy model have to create its own items to display the aggregates that are related to the original model items?
Yes but that doesn't change anything. QSortFilterProxyModel also creates some internal data for the proxied model.


My current understanding of proxy models is that they only filter/sort/re-format existing items.
They can manipulate the model in any way.

If you don't feel comfortable with calling it a "proxy", you can implement it as a custom model completely independent of the model it observes. Just connect to appropriate signals of the original model and you're good to go.

[Phlucious]

Another thread helped me to understand that I've been approaching the model-view concept from an item-based approach and that had I never actually made the plunge to thinking about it in terms of models, so what you say now makes a lot more sense. Thanks for your help!