[Qt-interest] Using true database cursors with Qt

[Josiah Bryan]

Robert Hairgrove wrote:
> 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.
>>
>> Thanks,
>> John Moran
>>     
>
> I'm not familiar with PostgreSQL, but what you describe sounds something 
> like DB2 or Oracle's array fetch. I don't think that Qt provides that 
> functionality.
>
> If you want to fetch only a subset of the data, and you have everything 
> indexed according to some scalar value (perhaps a sequential number) 
> then you could just partition the range of key values according to how 
> many rows you wanted to fetch. That would have the advantage of being 
> able to write DBMS-independent code.
>   

Um.. "fetch only a subset" - wouldn't the SQL construct "limit 50, 100" 
work for fetching "only a subset" or am I missing something deeper here?

-josiah