[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 

You can read more about Qt and databases here:


Roland Hughes, President
Logikal Solutions
(630) 205-1593


-------------- 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