@swankster , @ankou29666
I smacked together the following to test with a database backend:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QTableView w;
QFile::remove("sqlitedb.db");
QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE");
db.setHostName("localhost");
db.setDatabaseName("sqlitedb.db");
bool ok = db.open();
Q_ASSERT(ok);
QSqlTableModel myModel(nullptr, db);
QSqlQuery q;
ok = q.prepare("CREATE TABLE t1(row INT, col0 INT, col1 INT, col2 INT, col3 INT, col4 INT, col5 INT, col6 INT, col7 INT, col8 INT, col9 INT)");
if (!ok)
qDebug() << q.lastError().driverText() << q.lastError().databaseText();
ok = q.exec();
if (!ok)
qDebug() << q.lastError().driverText() << q.lastError().databaseText();
for (int row = 0; row < 56000; row++)
{
ok = q.prepare("INSERT INTO t1 VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)");
if (!ok)
qDebug() << q.lastError().driverText() << q.lastError().databaseText();
q.bindValue(0, row);
for (int col = 1; col <= 10; col++)
q.bindValue(col, col);
ok = q.exec();
if (!ok)
qDebug() << q.lastError().driverText() << q.lastError().databaseText();
}
myModel.setTable("t1");
myModel.select();
qDebug() << myModel.rowCount();
w.setModel(&myModel);
w.show();
return a.exec();
}
I admit I am using SQLite rather than MySQL, because I can't be bothered to figure out my MySQL. It takes quite a while to insert all the rows, but thereafter the scrolling is regular, fast and smooth. (About 1,000 rows every 2 seconds with my finger on Page Down key on the table view, which I suspect is down to the key auto-repeat rate rather than fetching/displaying rows, and certainly fast enough for the user.)
Note that the initial qDebug() << myModel.rowCount(); does indeed print 256 as I suggested would be the case. The Qt SQL code fetches "buffers" of 256 rows at a time. If/when you want more you have to call fetchMore(). The QTableView is doing this internally in response to the scrolling whenever it reaches the end of the latest buffer. There might be a tiny pause each time, though too fast to tell. And once fully populated I can scroll up & down freely.
YMMV. MySQL will certainly require a cross-process access compared against SQLite's direct file access. And if your MySQL database/server is on another machine that will be an overhead.
Why don't you start by seeing how this performs for you?
The only thing I can think of which could cause a "delay/lag" is when the view needs to request the next 256 rows from the db. This would occur during table view scrolling. But it should not become any progressively worse as more records have ben read. You can do all the fetchMore() calls yourself in advance (while (canFetchMore()) fetchMore();) to fully populate the model before displaying the view. From that you should see how much delay they cause on their own and you can see the view's behaviour when there is no database access going on.
Over to you, @swankster ! I really don't know exactly what you are doing or what your situation is. My own finding/belief is that it should work as shown in your situation without excessive lag and without all your pre-processing shenanigans.
