Re: Query tool results in grid

On 20/2/06 19:29, "Edward Di Geronimo Jr." <edigeronimo(at)xtracards(dot)com>
wrote:

>> We need a rewrite of ctlSqlResult, but it must base on a virtual
>> wxListBox or wxListView, i.e. maintaining the data ourselves. On the
>> long run, extending ctlSqlBox to use it in View Data would be desirable.
>
> My concern isn't speed but rather functionality. It doesn't really matter
> to me if wxGrid is 10x slower than wxListView if wxListView doesn't do
> what I need.

Unfortunately though, speed is the major complaint we get about that
particular part of the code. People use it (as was partly intended) to fine
tune their queries, and 10 minutes later are posting to a mailing list
asking why PostgreSQL is so slow, not realising that much of elapsed time is
not spent running their query or transferring the data, but populating the
grid.

This problem is partly alleviated by handing the double timing display, but
that still rarely helps.

> It would make my life a lot easier in at my job if I could
> copy arbitrary subsets of the results into the clipboard. I almost never
> want to copy entire rows at a time. As far as I can tell from the
> documentation, you can't do that with wxListView. As far as I'm concerned,
> this feature is the difference between pgAdmin being pleasant to use
> verses being one of those programs you curse at all the time.

Also agreed (yes, we want the best of all worlds :-p ) - copying partial
rows as well as full ones is important.

> My full intentions were to improve the implementation as soon as I got the
> base functionality working ok. I assumed a custom table class would be
> necessary for decent performance. I also intended on sharing as much code
> as possible between the result view and the view data grid.

'K.

> Also, I'm not seeing the relevance of ctlSQLBox. It doesn't sound useful
> at all to me for dealing with table data.

No, I'm not sure about that either.

> If you still think I should stop, let me know. If I'm missing something in
> the documentation and there is a better way to get the functionality I
> want, let me know.

No, please don't stop! We just need to make sure this is going the right
way. I'm afraid I can't look into the details to offer any help myself at
the moment, but I'm sure Andreas will keep an eye on any discussion.

My first though is that we need to abstract the data away from the grid so
that it loads into memory, and then just the visible rows before declaring
to the user that the query is complete. Then, background population of the
grid can occur as the user scrolls, 100 or 1000 rows (or whatever) at at
time on demand. In theory that should mean that pretty much any grid or
listview control can be used as only the UI will be constrained by it's
speed, not the query itself.

Regards, Dave.