[Interest] Interest Digest, Vol 91, Issue 26
Roland Hughes
roland at logikalsolutions.com
Thu Apr 18 16:36:49 CEST 2019
On 4/18/2019 5:00 AM, interest-request at qt-project.org wrote:
> Il 17/04/19 23:40, Scott Bloom ha scritto:
>> I have a source model, which is QSqlModel based, and a filter proxy model.
>>
>> Its not possible to make the filter part of the SQL query.. been down
>> that road…
>>
> Mind elaborating? Why not?
>
> Cheers,
The short answer is that MVVC doesn't work in the real world. The much
more in-depth answer takes up a full chapter in my new book.
The "filter" for SQL is the WHERE clause on the SELECT statement. A
"filter" in the C++ world works on the result of the query. Worst case
it doubles the memory and transfer resources required. When the goal is
reduction of required resources, a filter after the fact cannot help.
I too have had to deal with this on very large, not even real,
databases. You have to create your own model which can store 3 "pages"
of results. All of the database I/O has to be done in a background
thread (as other posters have found). Doing any real I/O in the primary
thread completely locks it up, especially for remote databases on slow
transfer paths.
The paging part isn't so bad for display. When the visible range gets
within X% of either boundary you send off another request to get the
next N-hundred rows occurring before or after (depending on direction)
the range currently in your model.
The difficult part is when they want an "accurate" scrollbar and the
non-database database is collecting readings from multiple sensors 5
times per second per sensor. They were using a version of SQLite which
meant no triggering of a stored procedure that could communicate to the
outside world. This puts a serious burden on the system because your
position is relative to the count for the ORDER BY clause of the select.
You can somewhat reduce this overhead by performing that count on a
timer AND changing the scroll bar unit from row/record to "page".
It gets real fun when the client adds the requirement that once a user
scrolls to the "end" of current data in a graph the graph should "lock
live" updating near real time. It is nice and entertaining to watch, but
most of the graphing tools come from a PC mindset, not a real world
mindset. They want a full set of data to calculate the axis values. When
your model has to lop off a page before adding another it can cause fun
times.
You can read more about Qt and databases here:
http://www.theminimumyouneedtoknow.com/qt_book.html
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190418/ae03550d/attachment.html>
More information about the Interest
mailing list