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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.