[Qt-interest] Using true database cursors with Qt

[Bill King]

On 11/27/2009 12:14 AM, ext John Moran wrote:
> Hello,
>
> Once again, the issue is *impedance mismatch*; I do not want to
>   
I think you think that means something other than what it actually
means. Impedance mismatch in OO systems is the mismatch between tables
and the object layout.
> transfer the entire result set from the database to the application in
> one go, because it's too large. I want to fetch it in smaller
> increments (a subset *at a time*), updating the GUI between
> increments. The thing that blocks isn't the updating of the UI after
> we have the big result set object, the QSqlQuery. It's the transfer of
> the result set in one foul swoop - it tends to be a lengthy network
> round trip, with inefficient reading of binary data ( I know this
> happens in the real world with my application because I've seen it
> first hand). Therefore, doing anything with threads won't help - the
> thread where I collect results will block in exactly the same way,
> waiting for that massive result set to transfer, gaining me nothing. I
> want to update the UI in increments, so that the first few items are
> near instantly visible, and additional items gradually appear until
> the QTreeView is completely populated after a few seconds. This is a
> much better alternative to just blocking for a few seconds, which
> gives the impression that my app is broken.
>
> This is a problem that is solved by the use of database cursors:
> http://en.wikipedia.org/wiki/Cursor_(databases) . This isn't some
> esoteric proprietary feature of some RDBMS - it's in the SQL standard,
> and has been for some time. This is a common, well understood problem.
>
> Regards,
> John Moran
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>   
QSqlQuery is the class you want. Where the database supports scrollable
cursors, they are used. Where they don't, we emulated them (by deriving
from QSqlCachedResult). It's not an optimal solution, but it's a
solution nonetheless.
In this case however, data is fetched as it's requested. From
QPSQLResult::data:     const char *val = PQgetvalue(d->result, at(), i);
where at() is the record(tuple actually) number in the query.
It looks like the problem is elsewhere (what are your connection
options? etc). If you can give us a simple example that replicates the
issue, we'll add it to the autotest system and look at it as soon as we can.

Thanks,
Bill.

-- 
Bill King, Software Engineer
Qt Development Frameworks, Nokia Pty Ltd
Brisbane Office