Better way to store query results from db in Qt Lists
-
@mardzo said in Better way to store query results from db in Qt Lists:
querySelect.setForwardOnly(true);
the data filling is much fasterhttp://doc.qt.io/qt-5/qsqlquery.html#setForwardOnly :
Forward only mode can be (depending on the driver) more memory efficient since results do not need to be cached. It will also improve performance on some databases.
I'm (really quite) surprised this makes much difference, and intrigued. Are you using MySQL, on what platform, or what? How big is your resultset from your query?
@mardzo
We can not change the Qt base and its aspirations.
The only thing we can do is keep this information on the Qt side so that further operations are quick.Which @JNBarchan said well:
@JNBarchan said in Better way to store query results from db in Qt Lists:i.e. it represents a single row --- and then return a QList<RowClass>?
QHash <QString, RowClass> will be faster then QList<RowClass> .
For example:
struct RowClass { QDateTime dtIN; QDateTime dtOUT; QString rfid; } QHash<QString, RowClass> hash; while( querySelect.next() ) { QString rfid = querySelect.value( 0 ).toString(); QDateTime dtIN = querySelect.value( 1 ).toDateTime(); QDateTime dtOUT = querySelect.value( 2 ).toDateTime(); RowClass cls; cls.rfid = rfid; cls.dtIN = dtIN; cls.dtOUT = dtOUT; hash[rfid] = cls; }
-
@mardzo
We can not change the Qt base and its aspirations.
The only thing we can do is keep this information on the Qt side so that further operations are quick.Which @JNBarchan said well:
@JNBarchan said in Better way to store query results from db in Qt Lists:i.e. it represents a single row --- and then return a QList<RowClass>?
QHash <QString, RowClass> will be faster then QList<RowClass> .
For example:
struct RowClass { QDateTime dtIN; QDateTime dtOUT; QString rfid; } QHash<QString, RowClass> hash; while( querySelect.next() ) { QString rfid = querySelect.value( 0 ).toString(); QDateTime dtIN = querySelect.value( 1 ).toDateTime(); QDateTime dtOUT = querySelect.value( 2 ).toDateTime(); RowClass cls; cls.rfid = rfid; cls.dtIN = dtIN; cls.dtOUT = dtOUT; hash[rfid] = cls; }
QHash <QString, RowClass> will be faster then QList<RowClass> .
hash[rfid] = cls;
-
You are assuming that OP's
rfid
is a primary key (or at least unique). While that may be the case, the OP does not state that anywhere in his question. -
QHash
will only be faster thanQList
if the OP does multiple lookups by key field in his results. If he does not --- e.g. he just uses the values once to populate the UI, say --- it will actually be (marginally) slower & more memory.
-
-
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
@mardzo
Than as I said, stick withQList
, notQHash
, in your example.You still have to fill the
QStandardItemModel
one row at a time, there is nothing more efficient than that offered from Qt. In this case, of course, there is no need to involve aQList
, you do it straight fromquerySelect.next()
intoQStandardItemModel.setData()
. -
Im fetching results from a remote Microsoft SQL Server 2012 on a local network installed on a windows 10 machine. As this software is still in development i am currently fetching about 500 rows from 6 columns in a request
@mardzo said in Better way to store query results from db in Qt Lists:
Im fetching results from a remote Microsoft SQL Server 2012 on a local network installed on a windows 10 machine. As this software is still in development i am currently fetching about 500 rows from 6 columns in a request
I'm still surprised/intrigued that you say
setForwardOnly()
makes any (noticeable) difference to speed. Are you sure it does (i.e. you've run it a few times with and without)? (e..g It would be more likely that it's the "random" delay in response from remote SQL Server than the forward-only.) I'd be grateful if you confirmed this, as it might make a difference to me in code I have inherited --- thanks. -
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
@mardzo said in Better way to store query results from db in Qt Lists:
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
When I use QTableWidget and fill it with my class. I use a 0-bit column for UID-like. When I need to edit or delete this record in the database, I have this record UID in the QTableWidget's last row and in the 0-van column and this class from QHash is quicker.
If you're the same, I recommend you use QHash.@JNBarchan I wanted to say this from the beginning.
-
@mardzo said in Better way to store query results from db in Qt Lists:
Im fetching results from a remote Microsoft SQL Server 2012 on a local network installed on a windows 10 machine. As this software is still in development i am currently fetching about 500 rows from 6 columns in a request
I'm still surprised/intrigued that you say
setForwardOnly()
makes any (noticeable) difference to speed. Are you sure it does (i.e. you've run it a few times with and without)? (e..g It would be more likely that it's the "random" delay in response from remote SQL Server than the forward-only.) I'd be grateful if you confirmed this, as it might make a difference to me in code I have inherited --- thanks. -
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
Did you try running your program in Release mode? Debug mode for QtSql is quite heavy and might be the real bottleneck here (apart from network but that's not something you can control)
@mardzo said in Better way to store query results from db in Qt Lists:
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel
Then why are you putting a further step inbetween? just fill the model in the query loop.
-
@mardzo said in Better way to store query results from db in Qt Lists:
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
When I use QTableWidget and fill it with my class. I use a 0-bit column for UID-like. When I need to edit or delete this record in the database, I have this record UID in the QTableWidget's last row and in the 0-van column and this class from QHash is quicker.
If you're the same, I recommend you use QHash.@JNBarchan I wanted to say this from the beginning.
@Taz742 said in Better way to store query results from db in Qt Lists:
@mardzo said in Better way to store query results from db in Qt Lists:
Just to clarify, rfid is not a primary key, and once i fetch the data, i am using it to fill a QStandardItemmodel and display it in a QTableView in the ui
When I use QTableWidget and fill it with my class. I use a 0-bit column for UID-like. When I need to edit or delete this record in the database, I have this record UID in the QTableWidget's last row and in the 0-van column and this class from QHash is quicker.
If you're the same, I recommend you use QHash.@JNBarchan I wanted to say this from the beginning.
Before we confuse the OP, he wants to use
QStandardItemModel
, and as @VRonin & I have said, he should not go via eitherQList
orQHash
, he should just fill the model in the query loop.Next bit for @Taz742 only:
Assuming you only show, say, at most 100 rows to the user (you don't want to show thousands, do you), and do the occasional one-time lookup of a column I can't see it will be faster with a
QHash
than aQList
(assuming you remember to count the time for populating theQHash
as well as the single lookup). But whatever.What I don't get, however, is why you're doing any lookup at all? From a
QTableWidget
/QTableView
, isn't the whole point to use theQModelIndex
functions to map directly from the view to the row in the model, and use that, without any searching?