Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
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.
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?
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.
JonB last edited by
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...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 with
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?
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 last edited by
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?
What database are you using ?
@JonB Hi, your reply helped me a lot. I will try to customize a UI data model to connect to a separate database thread in the form of Signals/Slots.
@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?
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.
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...
@SGaist Hi, since these days are the Chinese New Year, I am sorry to see your reply so late, and I will seriously consider your solution.
Happy New Year!