Exception of multi thread reading QSqlTableModel

JonB

@tovax
Most important decision: do you really mean that thread1 must physically write to the database and thread2 must physically (re-)read the data from the database, or do you mean that thread2 can/should read the (changed) data in-memory.

SGaist

@tovax from the looks of it you are missing one component: the controller.

Your use case is typically one that should rather use MVC rather than just MV.

One thing that is not clear is how are you child threads triggered ?

Are you creating them on demand on are they long-lived ? In both cases, the suggestions from @KroMignon are good in terms of encapsulation of the threaded components and separation of the storage side.

@JonB The one connection per thread rule is rather a constraints of the class design: you shall not use the exact same database connection from different threads in the same spirit as you should not modify GUI object outside the GUI thread.

KroMignon

@tovax said in Exception of multi thread reading QSqlTableModel:

For example, the results generated by child thread1 need to be written to the database, and used by child thread2.

You can solve this with signals/slots:

Client1: you need a signal (or more) for writing result, which can be connected to Main to store in DB and to Client2 to update his parameters.
Client2: you need a signal for writing new position
Main: you need a signal to setup Client1 and another to setup Client2

Maybe Client1 and Client2 needs an additional signals to request settings update.
But that don't seems to be a very difficult architecture to implement.

JonB

@SGaist said in Exception of multi thread reading QSqlTableModel:

@JonB The one connection per thread rule is rather a constraints of the class design: you shall not use the exact same database connection from different threads

Absolutely, as I said from the start! The question at hand is whether for this user's case he should indeed go for separate connections per thread, or whether he should work on "shared" (somehow) data.

Since @Christian-Ehrlicher has not replied to it, could you kindly answer my earlier question, at least for my information:

Isn't the following a problem: is it not the case that for a reader accessing data() that calls rowCount() and that can cause physical call to database for fetchMore()?? Or does data()/rowCount() never do that, I can't recall?

tovax

@JonB
First of all, the data generated by each child thread must be written to the database in order to prevent sudden power failure. Then, the data generated by each child thread can be shared with each other threads.
I just think the unified use of the database is logically simpler, thread2 can read the changed data in memory.

tovax

This post is deleted!

tovax

tovax

@KroMignon said in Exception of multi thread reading QSqlTableModel:

Maybe Client1 and Client2 needs an additional signals to request settings update.

Thank you for your detailed steps. The actual application is much more complicated than the block diagram, so I'm worried that this method will need to create too many signal slots.

tovax

Based on your discussion, I think that creating database connections for each child thread is not my best choice, because the actual situation is much more complicated than the block diagram.

tovax

In the main thread to create a unique database connection, other child threads interact with the main thread to achieve read/write the database. I know that the signal-slot can easily write data to the database, so what is the best way to read data?

tovax