QSqlTableModel, QTableView and sqlite databases: how to use/reuse them in the same program

[sairun]

Thanks @JonB for noticing the unchecked deleteLater() but at this stage of the program I can at least be sure that the olmodel pointer is pointing to something because it was being used. Still, it's better to make sure the pointer is not null! The old selection model olselmod is another thing. In fact, the code in github that I've linked previously doesn't mention the selectionModel() anywhere in the sources. But valgrind didn't show any major leak, so I'm not sure if it is being dealt aitomatically.

[JonB]

@sairun
I wasn't sure whether selectionModel() could potentially be nullptr if, say, you never do a selection. Probably not. But better safe than sorry.

I rely on valgrind for checking Qt/C++ memory is being disposed correctly. If it passes you should be good. You could try not doing the disposals and verify it then complains.

[sairun]

Don't get me wrong @JonB. I prefer to do the checking. The issue is whether I care about selectionModel or not. I've never had the need to directly intercat with it, although I know it is being used in my program. I rely on the selection of rows in a view to export some data.

[JonB]

@sairun
Yes, if you use selection then the QItemSelectionModel will come into play. You should indeed delete or deleteLater() it as you are doing, else I think it may leak. I only meant that I do not know whether view->selectionModel() is always guaranteed to be allocated and non-nullptr, if it can be nullptr then your original unprotected code would crash, so it's worth putting in the check. I think we are on the same page :)

[Christian Ehrlicher]

@JonB said in QSqlTableModel, QTableView and sqlite databases: how to use/reuse them in the same program:

You should indeed delete or deleteLater() it as you are doing, else I think it may leak.

No, it does not.

https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/itemviews/qabstractitemview.cpp#n797

[JonB]

@Christian-Ehrlicher
QAbstractItemView::setSelectionModel(QItemSelectionModel *selectionModel)

Note: It is up to the application to delete the old selection model if it is no longer needed; i.e., if it is not being used by other views. This will happen automatically when its parent object is deleted. However, if it does not have a parent, or if the parent is a long-lived object, it may be preferable to call its deleteLater() function to explicitly delete it.

That is what the OP is trying to follow. I do not know what his parent is. At least this is what I was thinking of, and the examples OP has found on the web.

[sairun]

@Christian-Ehrlicher, what you mean is that per source code the QItemSelectionModel is set as a child of QAbstractItemModel and will be deleted when the latter is deleted? So I only have to deal with the model and not the selection model?

[Christian Ehrlicher]

@sairun said in QSqlTableModel, QTableView and sqlite databases: how to use/reuse them in the same program:

So I only have to deal with the model and not the selection model?

Yes

[sairun]

@Christian-Ehrlicher said in QSqlTableModel, QTableView and sqlite databases: how to use/reuse them in the same program:

Yes

I see. So the documentation isn't correct in the code snippet I showed above... I should mention that I implemented the deletion of the QTableModel without referencing the QItemSelectionModel` as suggested, and so far everything is working as expected. I'll mark this as solved.

[Christian Ehrlicher]

@sairun said in QSqlTableModel, QTableView and sqlite databases: how to use/reuse them in the same program:

isn't correct in the code snippet I showed above..

I don't see a problem here:

It is up to the application to delete the old selection model if it is no
longer needed; i.e., if it is not being used by other views. This will happen
automatically when its parent object is deleted.

The parent is QAbstractItemView so the QISM is deleted when the itemview gets deleted.