Kalle Hallivuori wrote:
> Actually, I'm still wondering how to do this. We need to
>
> 1. submit the SELECT to server so that it produces a CURSOR instead of
> a result set,
> 2. fetch and view rows from CURSOR instead of a ready-made result set,
> 3. handle a new state where a query is running but passive in a way
> which enables more interaction than just stopping the current query.
> Maybe we can call this state "active".
>
> I'm reading the code but I'm still not crystal clear on where and how
> to make those changes. That is where I'm welcoming input. Maybe there
> are some classes, methods or properties that you could point me to? If
> you've considered it yourself, which parts of code have you thought
> you would change, and how?
I haven't looked at it in that much detail for a number of years
unfortunately. However, from the top of my head, I would start by
looking at ctlSQLResult::Execute/pgQueryThread::execute in which you can
create the cursor and retrieve the first batch of results. Then, look at
extending pgSet such that when run with a cursor, an attempt to access a
row that hasn't be retrieved yet results in the dataset being extended
before the value is returned. Currently pgSet is tied to a single
PGResult, but I guess in cursor mode we would probably need to make that
a list of PGResults each containing <= N rows where N is a configurable
batch size.
It shouldn't be too hard to tie this low level stuff in with the UI
because the grid control will automatically request data as it renders
each row.
Like I said though, this is largely off the top of my head, so I may
have missed a showstopper somewhere :-). Feel free to ping more
questions or ideas to the list for discussion though.
/D
