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,
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.