[Interest] Issue with QSqlModel and QSortFilterModel

[Bernhard Lindner]

Did you write an issue tracker entry about that?

> As a matter of fact I was facing a similar issue for my current project, but in my case
> I need to fetch the data over the network, from a DB as well, but one that I don't have
> direct access to. You can imagine I struggle(d) as you with how to orchestrate the whole
> thing. Unfortunately, what I concluded is that the model framework is designed in such a
> way that it's not possible out of the box to run high-latency operations. To give an
> example - take QAbstractItemModel::canFetchMore and QAbstractItemModel::fetchMore, on
> the one hand it's well intentioned to allow the underlying data layer to fetch data
> incrementally, the problem is the assumption(s) that are made, namely that fetchMore is
> going to return when the data is available (i.e. populate the data synchronously),
> otherwise you just stick to the default implementation, which does nothing. There's no
> fetchMore and a fetchedMore counterpart and so on ... Note, also, that the model is
> often not well suited to hold the actual data, except in the simplest of cases. 
> 
> What I ended up doing in the end is to "invent" a real data layer, to which my derived
> model (think QAbstractItemModel implementation) is a proxy. The data source signals the
> changes and the model just (re)translates the (internal) identifiers into QModelIndex
> instances for the view. This comes with its own battery of problems and is quite a lot
> of work, but it seems to work well. Bear in mind that when I start-up the model and the
> data source, I stream (in manageable chunks) all the data for the model to the client,
> and then handle the changes as unsolicited notifications from the network peer (i.e. the
> server). As far as my research into the issue goes, depending on the internal framework
> for incremental loading is futile. The model-view framework doesn't care about partial
> datasets, it only cares that the children data for a given parent index is loaded; it
> has no notion of paging the data.
> What was somewhat challenging was to batch-up the inserts/updates/deletions that are
> signaled from the data source, because the model expects them to be grouped by parent,
> which naturally isn't always the case; in the end there is some boilerplate to organize
> that as well. As for the filtering part, currently I have a couple of sort-filter
> proxies, but as work goes along I'm planing to wrap up my own filter proxy that has
> multiple filter fields. For large(-ish) datasets the multiple model index remappings eat
> a lot of time and memory.
> 
> I hope that helps you a bit
> 
> Kind regards,
> Konstantin.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards
Bernhard Lindner