Solved GUI thread and non-GUI thread operate the same database
-
@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...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 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?
-
@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 ?
-
@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! -
@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? -
@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...
-
@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!