GUI thread and non-GUI thread operate the same database
-
The GUI thread is a QWidget, which contains some QLineEdit for setting parameters and QLabel for displaying information. These QLineEdit and QLabel have been mapped to the database through QDataWidgetMapper.
Non-GUI threads also need to read and write the contents of these QLineEdit and QLabel.
For example, the QLineEdit used to set the speed can be entered by the user with a certain speed value, but the speed value may be inappropriate. The non-GUI thread will obtain the speed value and correct the speed value during execution. The non-GUI thread will frequently generate some information when it is running, and this information needs to be displayed in the GUI thread and saved to the database.Solution A
The solution I tried is this: create a database connection separately in the GUI thread and the non-GUI thread, and any modification will be written to the database immediately, but the model data of these two threads will not be updated synchronously. Because there is no way to know that QSqlDatabase has been refreshed.
Due to the large amount of data (some display information is refreshed frequently), it is very inefficient to re-query model data (using model->select()) by sending update signals. Is there any way to make GUI thread and non-GUI thread operate the same database synchronously?Solution B
There is another solution: connect GUI threads and non-GUI threads through signal slots.
Due to the rapid data update, the queue connection may affect the performance of the GUI thread. -
The GUI thread is a QWidget, which contains some QLineEdit for setting parameters and QLabel for displaying information. These QLineEdit and QLabel have been mapped to the database through QDataWidgetMapper.
Non-GUI threads also need to read and write the contents of these QLineEdit and QLabel.
For example, the QLineEdit used to set the speed can be entered by the user with a certain speed value, but the speed value may be inappropriate. The non-GUI thread will obtain the speed value and correct the speed value during execution. The non-GUI thread will frequently generate some information when it is running, and this information needs to be displayed in the GUI thread and saved to the database.Solution A
The solution I tried is this: create a database connection separately in the GUI thread and the non-GUI thread, and any modification will be written to the database immediately, but the model data of these two threads will not be updated synchronously. Because there is no way to know that QSqlDatabase has been refreshed.
Due to the large amount of data (some display information is refreshed frequently), it is very inefficient to re-query model data (using model->select()) by sending update signals. Is there any way to make GUI thread and non-GUI thread operate the same database synchronously?Solution B
There is another solution: connect GUI threads and non-GUI threads through signal slots.
Due to the rapid data update, the queue connection may affect the performance of the GUI thread.@tovax
My 2 cents/understanding. I wouldn't want to create multiple database connections, or try to sync. Database operations should only be done in the thread whereQ...Databaseis created/owned/moved to. Solution B, with a separate database thread and signals being sent from UI to database thread when necessary, keeping UI thread responsive. I don't know how that interacts withQDataWidgetMapper. -
@tovax
My 2 cents/understanding. I wouldn't want to create multiple database connections, or try to sync. Database operations should only be done in the thread whereQ...Databaseis created/owned/moved to. Solution B, with a separate database thread and signals being sent from UI to database thread when necessary, keeping UI thread responsive. I don't know how that interacts withQDataWidgetMapper.@JonB said in GUI thread and non-GUI thread operate the same database:
My 2 cents/understanding. I wouldn't want to create multiple database connections, or try to sync. Database operations should only be done in the thread where Q...Database is created/owned/moved to.
In other words, I should not continue to consider Solution A?
-
@tovax
My 2 cents/understanding. I wouldn't want to create multiple database connections, or try to sync. Database operations should only be done in the thread whereQ...Databaseis created/owned/moved to. Solution B, with a separate database thread and signals being sent from UI to database thread when necessary, keeping UI thread responsive. I don't know how that interacts withQDataWidgetMapper.@JonB said in GUI thread and non-GUI thread operate the same database:
Solution B, with a separate database thread and signals being sent from UI to database thread when necessary, keeping UI thread responsive. I don't know how that interacts with QDataWidgetMapper.
Thank you for your answers, I have to consider whether it is appropriate to map the GUI data directly to the database.
-
@JonB said in GUI thread and non-GUI thread operate the same database:
Solution B, with a separate database thread and signals being sent from UI to database thread when necessary, keeping UI thread responsive. I don't know how that interacts with QDataWidgetMapper.
Thank you for your answers, I have to consider whether it is appropriate to map the GUI data directly to the database.
@tovax
Well I wouldn't do A, I would do B, in some shape or form.I have to consider whether it is appropriate to map the GUI data directly to the database.
I don't quite know what this means. Like we said, all db ops would be done by db backend thread. UI would send signal to it. So if UI value for something is not good/right, backend (or UI in signal) can still map that to appropriate for the db?
-
Hi,
What database are you using ?
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@tovax
Well I wouldn't do A, I would do B, in some shape or form.I have to consider whether it is appropriate to map the GUI data directly to the database.
I don't quite know what this means. Like we said, all db ops would be done by db backend thread. UI would send signal to it. So if UI value for something is not good/right, backend (or UI in signal) can still map that to appropriate for the db?
-
@SGaist Hi, thank you very much for your reply, it's SQLITE.
Multiple threads operate on the same database. When one thread writes to the database, other threads cannot know that the database has been updated without a signal trigger. In other words, QSqlDatabase will not notify QSqlTableModel to query the database again. Is my understanding correct, please? -
@tovax
Well I wouldn't do A, I would do B, in some shape or form.I have to consider whether it is appropriate to map the GUI data directly to the database.
I don't quite know what this means. Like we said, all db ops would be done by db backend thread. UI would send signal to it. So if UI value for something is not good/right, backend (or UI in signal) can still map that to appropriate for the db?
@JonB
Solution C
The UI mapped to the custom data model, and the database model runs in a backend thread. In this way, communication between other control threads and database thread will use cross-thread database connections, which should not be allowed.
Solution D
The UI mapped to the database model, and the custom data model runs in a backend thread. After the custom data model is locked, it can be safely read and written by other control threads. -
Solution E: use update_hook from SQLite, but this will require some compilation...
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Solution E: use update_hook from SQLite, but this will require some compilation...
