<![CDATA[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.

]]>https://forum.qt.io/topic/123622/gui-thread-and-non-gui-thread-operate-the-same-databaseRSS for NodeFri, 09 Oct 2026 10:11:53 GMTTue, 09 Feb 2021 10:39:14 GMT60<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Fri, 19 Feb 2021 02:34:51 GMT]]>@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!

]]>https://forum.qt.io/post/645339https://forum.qt.io/post/645339Fri, 19 Feb 2021 02:34:51 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Wed, 10 Feb 2021 20:41:28 GMT]]>Solution E: use update_hook from SQLite, but this will require some compilation...

]]>https://forum.qt.io/post/643734https://forum.qt.io/post/643734Wed, 10 Feb 2021 20:41:28 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Wed, 10 Feb 2021 01:07:12 GMT]]>@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.

]]>https://forum.qt.io/post/643498https://forum.qt.io/post/643498Wed, 10 Feb 2021 01:07:12 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Wed, 10 Feb 2021 00:06:29 GMT]]>@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?

]]>https://forum.qt.io/post/643496https://forum.qt.io/post/643496Wed, 10 Feb 2021 00:06:29 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 23:54:16 GMT]]>@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.
Best regards!

]]>https://forum.qt.io/post/643494https://forum.qt.io/post/643494Tue, 09 Feb 2021 23:54:16 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 18:15:19 GMT]]>Hi,

What database are you using ?

]]>https://forum.qt.io/post/643421https://forum.qt.io/post/643421Tue, 09 Feb 2021 18:15:19 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 12:49:02 GMT]]>@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?

]]>https://forum.qt.io/post/643368https://forum.qt.io/post/643368Tue, 09 Feb 2021 12:49:02 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 11:10:14 GMT]]>@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.

]]>https://forum.qt.io/post/643334https://forum.qt.io/post/643334Tue, 09 Feb 2021 11:10:14 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 11:03:18 GMT]]>@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?

]]>https://forum.qt.io/post/643332https://forum.qt.io/post/643332Tue, 09 Feb 2021 11:03:18 GMT<![CDATA[Reply to GUI thread and non-GUI thread operate the same database on Tue, 09 Feb 2021 10:48:19 GMT]]>@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 where Q...Database is 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 QDataWidgetMapper.

]]>https://forum.qt.io/post/643330https://forum.qt.io/post/643330Tue, 09 Feb 2021 10:48:19 GMT