The story is that I am writing a model that represents SQL-table as a tree. Consider the following table definition:
CREATE TABLE IF NOT EXISTS document (
id INTEGER PRIMARY KEY AUTOINCREMENT,
parent_id INTEGER,
FOREIGN KEY(parent_id) REFERENCES document ON DELETE CASCADE,
CHECK (id != parent_id)
)
Primarily, I used QAbstractItemModel, because this is the most general class which has to be designed to allow any degree of customization. Everything worked fine, until I discovered QAbstractProxyModel which provides mapToSource() and mapFromSource() methods. Well, that is, basically, what I am doing — just mapping indices back and forth between tree and table models. So, I have changed the design of my class to inherit from QAbstractProxyModel and it stopped working correctly.
Analyzing the Qt’s sources I have figured out that QAbstractProxyModel mostly delegates the responsibility for logic to the underlying (i.e. so-called source) model. Such delegation is achieved by overriding a plenty of virtual methods and call the same-named methods of the underlying model, considering mapToSource(), mapFromSource() conversions of indices.
When I overrode QAbstractProxyModel’s methods to fall back to QAbstractItemModel’s implementation, I made my class working again. So, the question is whether QAbstractProxyModel is appropriate for such indices-mapping logic, when the relationship topology of items changes drastically, or its use is just to alter data insignificantly, like sorting/filtering?
↧