[Qt-interest] Using true database cursors with Qt

[Andre Somers]

John Moran wrote:
> Hi Robert,
>
>   
>> I believe that QSqlQuery provides exactly the same functionality as a
>> cursor. There might be some things you could do to improve performance
>> on the database side of things, though:
>>     
>
>   
>> (1) proper indexing;
>>     
>
> Naturally, I already index things; My real concern is so-called
> "impedance mismatch" though.
>
>   
>> (2) fetch pre-built thumbnails instead of entire full-sized images to
>> populate your list;
>>     
>
> They're already thumbnails.
>
>   
>> (3) call QApplication:;processEvents() within your loop which should
>> help keep the GUI responsive.
>>     
>
> That's what I intend to do, between cursor fetches; The point of the
> cursor is that it encapsulates a result set. I don't have to transfer
> all the results between the database and my app at once. I can fetch a
> bunch of them at a time, and call QApplication:;processEvents()
> between fetches. I think it's pretty doubtful that QSqlQuery is
> transparently using a *native* cursor (the only useful kind - I think
> some python DB drivers use the term cursor without actually using
> native cursors). Surely the docs would say so, and surely I'd be able
> to specify how many records I want to fetch at a time, between calls
> to  QApplication:;processEvents(). This would typically work my
> instantiating a cursor class, which we iterate through. Each iteration
> would return a subset of the cursor's result set, perhaps in the form
> of a QSqlQuery. We'd be using a nested loop. This is how the regular
> C++ postgreSQL API, libpqxx, does it.
>
>   
Is the problem you're talking about a real-world one, or are you 
expecting this issue somehow? It's little use trying to fix an issue 
that does not actually occur...

What I would do if I had your doubts, was just put the whole SQL loading 
in a separate thread, and communicate the resulting data in batches to 
the GUI thread.

André