Qt models behind proxies and fetchMore()/canFetchMore()

Question

I am interested to know how would views behave in cases when the main data model with incremental data fetching is behind a proxy or chain of proxies.

How proxy which does item rearrangements like ungrouping proxy (example: http://lynxline.com/jongling-qt-models/) should implement support of fetchMore()/canFetchMore()?

Answer 1

Examining QSortFilterProxyModel's source allows me to conclude that:

• QSortFilterProxyModel allows access to already fetched rows. Calling rowCount, data, etc. will behave like there is no more data in the source table.
• QSortFilterProxyModel (and QAbstractProxyModel by default) routes canFetchMore and fetchMore calls to according methods of the source model.

It means that when you scroll down a view with a QSortFilterProxyModel populated from a dynamically fetched table, it will be dynamically populated with new data from source model. However you can't be sure that new items will be added to the end. Instead, when scrolling down the table, its data can completely change. New rows can be added anywhere depending on current sorting and filtering settings.

When no additional support of canFetchMore and fetchMore is given, all proxy models (including the linked UngroupProxyModel class) will behave like that by default.

QTableView behaves buggy displaying such models. For example, if the source model has rows -2; -3; 2; 3 (let ; be a row separator in my answer), the view without sorting would usually display something like -2; -3; 2; 3; empty row; empty row. Empty rows are displayed in the bottom of the table. When user scrolls down enough close to these items, the view requests fetching more data. However, when sorting is enabled, the view shows -3; -2; empty row; empty row; 2; 3, i.e. it moves empty invalid rows to the middle or to the top of the table. It doesn't affect functionality but looks awkward.

However, all aforementioned issues are implementation dependent. Refer to the code and documentation of the used model classes for more details. I think it's possible to implement proxy models that act however you like.

Also, it would be reasonable in some cases to fetch source model completely before displaying sorted data in the table. Proper sorting or joining is impossible while not all data has been fetched. If you fetched the source model data (e.g. while(model->canFetchMore()) { model->fetchMore(); }) then proxy models will behave exactly like the model is not dynamically populated.