QAbstractProxyModel has broken semantics or misused?
-
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 calls 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?
-
If you use a SQL table then you should use QSqlQueryModel or QSqlTableModel. QTreeView represents the tree structure and it's design to work with models. Read about these classes - maybe will be useful.
-
Neither of these two model classes create a tree structure, even though you can of course display them in a QTreeView, you will not be able to drill into your data by opening branches. So no, that suggestion is not going to help Dmitrii.
-
Your are right that these two model classes not creates a tree structure but I write about them because they works on SQL. I think that subclassing from these classes give a more(sql operations) than minimal QAbstractItemModel or QAbstractProxyModel.
-
Thanks everybody for the input. I've ended up with class inheriting QAbstractItemModel which agregates QSqlTableModel.
-
Would it be possible for you to contribute that class to the wiki perhaps, so others with similar problems could use it as well? I guess it could be generic enough right?
-
Andre, I would be happy to do that, but I am not sure of the right place where it fits the best. Not yet very familiar with Qt's Wiki's infrastructure. Requesting for suggestions.
-
That would be great!
What you could do, is create a Gitorious repository for the actual sources, and then write a wiki article describing the class and containing a link. Check out the "snippets":/wiki/Category:Snippets category for other articles with code samples. Also, if you post the code in a repository, please add a LICENSE file to it and also put the license in the headers, so it is clear if this code is OK for someone to use in a project.
