Multiple QSqlTableModels on single widget
-
All,
I'm having some performance issues when moving my application to a cloud-based SQL server through Azure (testing was done on a local SQL server which was masking these issues).
On a custom widget I have a QSqlTableModel linked to a QTableView and QDataWidgetMapper shown in green and red below. When the user changes their selection in the view on the left in green, the data mapper is updated via the private slot below. In addition to updating the mapper, the slot also calls a function to update a second QSqlTableModel based on the primary key of the selection and displays this in a second QTableView (in blue below).
Testing with QElapsedTimer is giving me between .5 and 1.0 second delays on each index change which is slow enough to make the UI feel clunky now. Is there a way to move this second QSqlTableModel and QTableView to another thread, or some other method to improve performance?
I would think many SQL-backed applications would have multiple views/models in a single widget so it seems like there should be a solution here that I'm missing.
Appreciate any insights.
void PolicyWidget::updateMappedData(const QModelIndex ¤t, const QModelIndex &previous) { Q_UNUSED(previous); m_mapper->setCurrentIndex(current.row()); updatePayrollInfo(); //Can this be moved to a separate thread? }
-
All,
I'm having some performance issues when moving my application to a cloud-based SQL server through Azure (testing was done on a local SQL server which was masking these issues).
On a custom widget I have a QSqlTableModel linked to a QTableView and QDataWidgetMapper shown in green and red below. When the user changes their selection in the view on the left in green, the data mapper is updated via the private slot below. In addition to updating the mapper, the slot also calls a function to update a second QSqlTableModel based on the primary key of the selection and displays this in a second QTableView (in blue below).
Testing with QElapsedTimer is giving me between .5 and 1.0 second delays on each index change which is slow enough to make the UI feel clunky now. Is there a way to move this second QSqlTableModel and QTableView to another thread, or some other method to improve performance?
I would think many SQL-backed applications would have multiple views/models in a single widget so it seems like there should be a solution here that I'm missing.
Appreciate any insights.
void PolicyWidget::updateMappedData(const QModelIndex ¤t, const QModelIndex &previous) { Q_UNUSED(previous); m_mapper->setCurrentIndex(current.row()); updatePayrollInfo(); //Can this be moved to a separate thread? }
@ZNohre said in Multiple QSqlTableModels on single widget:
Is there a way to move this second QSqlTableModel and QTableView to another thread
No, widgets and other Qt GUI elements have to live in the main thread where the Qt app was created.
How complex is your "mapping"? Have you figured out what exactly takes up to 1s?
I don't think it's theQSqlTableModel
which takes close to 1s to respond. -
@ZNohre said in Multiple QSqlTableModels on single widget:
Is there a way to move this second QSqlTableModel and QTableView to another thread
No, widgets and other Qt GUI elements have to live in the main thread where the Qt app was created.
How complex is your "mapping"? Have you figured out what exactly takes up to 1s?
I don't think it's theQSqlTableModel
which takes close to 1s to respond.@Pl45m4 Thank you, I had seen a few separate posts where it looked like multithreading wasn't possible in model/view so I'll stop exploring it. I agree there must be something else going on. I'll try stripping the class down to the basics to see what the issue is and will report back.
-
-
Marking as solved since the actual question re: multithreading was answered by @Pl45m4
For those having similar issues with performance on views/mappers connected to QSqlDatabase the issue here (as suspected above) was related to my mapping and connections. Essentially an internal helper function to update subtotals was being called hundreds of times. This was causing significant delays on navigation through the model, as well as initialization of the widget.