Unsolved QSqlDatabase problem !
-
What is the problem ?
class DatabaseThread : public QThread { Q_OBJECT public: DatabaseThread(const QString &connName,/* other params ...*/); void run() { conn = QSqlDatabase::addDatabase("QMYSQL", connectionName); conn.setHostName(hostName); conn.setPort(port); conn.setUserName(userName); conn.setPassword(password); if(databaseName != "") conn.setDatabaseName(databaseName); if(connectOptions != "") conn.setConnectOptions(connectOptions); bool result = conn.open(); if(!result) qDebug() << conn.lastError().text(); // other operations exec(); } private: QSqlDatabase conn;
int main(int argc, char *argv[]) { QApplication a(argc, argv); DatabaseThread *thread1 = new DatabaseThread("connname1", /*other connection params*/); thread1->start(); DatabaseThread *thread2 = new DatabaseThread("connname2", /*other connection params*/); thread2->start(); return a.exec(); }
Output :
QObject::moveToThread: Current thread (0x50ef60) is not the object's thread (0x50efb0).
Cannot move to target thread (0x4f01d8)"Can't create TCP/IP socket (10093) QMYSQL: Unable to connect"
BUT
DatabaseThread *thread1 = new DatabaseThread("connname1", /*other connection params*/); thread1->start(); QThread::msleep(2000); // new code DatabaseThread *thread2 = new DatabaseThread("connname2", /*other connection params*/); thread2->start();
No Problem.
-
I am not an expert in either threads or databases but I have used both successfully. Since nobody else has replied yet I'll give you some of my thoughts.
There is a thread out there about how to do Qt threads correctly. It suggests not subclassing a QThread but rather having a worker class and sending one of its objects to a QThread object using moveToThread. In your case the worker class would be a database connection. You do the initialisation, connect signals and slots for communication prior to doing the moveToThread.
I have had much luck with this model. There are some who say it usually won't matter, but they fail to say when it will and I don't know enough about threads to tell you if yours is a case when it would. All I can say is it has always worked for me.
As for databases, I'm a fan of Postgres, although I would think MySQL would probably have pretty much the same performance. I have never needed to go to threads because of database performance issues. My applications are on the light side though, being used in a small office. Still, you may consider threads as being a premature optimization of your program. A lot of the logic can be offloaded to the server using stored procedures, so your app doesn't need to work very hard at all.
Mike