Question

I’m trying to do a record-based in-grid editing with my own QAbstractTableModel-descendant class and a QTableView. When the editing is finished, the model recieves a signal to it’s submit() or revert() slots. But there are no parameters, so the model does not know which record it needs to submit to (refresh from) a datastore. I’ve tried to setup my own change-tracking by catching model.setData()/removeRows()/insertRows() , but it’s kind of a mess. Is there a right way to do it?

Answer 1

Per the docs on QAbstractTableModel:

Subclassing

When subclassing QAbstractTableModel, you must implement rowCount(),
columnCount(), and data(). Default implementations of the index() and
parent() functions are provided by QAbstractTableModel. Well behaved
models will also implement headerData().

Editable models need to implement setData(), and implement flags() to
return a value containing Qt.ItemIsEditable.

So the fact that you are re-implementing setData, removeRows, and insertRows is appropriate. The other subclasses of this class also use their own internal caching to track what is being changed, so that it can commit it to the data source when needed. If your approach is a mess so far, then you probably just need to improve what you are doing, as the path is correct.

setData is where you can track what is being changed in an internal data structure. So for instance, if your model were a basic dictionary internally, and would submit to a web-based REST service, you would manage changes to the data in your internal dict. When submit is called, you would use that internal cache to make the necessary REST call to send out the data and sync it.