Re: Lightspeed for frmQuery and other issues. - Mailing list pgadmin-hackers

From Edward Di Geronimo Jr.
Subject Re: Lightspeed for frmQuery and other issues.
Date
Msg-id 20060430122620.dfm9klqp3cgsoo08@webmail.picoip.com
Whole thread Raw
In response to Re: Lightspeed for frmQuery and other issues.  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: Lightspeed for frmQuery and other issues.
List pgadmin-hackers
Quoting Andreas Pflug <pgadmin@pse-consulting.de>:

> I still don't see a need for that extended handling, because the ctl
> always allowed row selections (and column selections can be achieved
> from SELECT ...., a basic SQL feature... )

Very often in my work, I would not know exactly what columns I need
the data from until after I see the results of the query. Someone
would walk into my office and say "What's wrong with Joe Smith's
account?" I'd run a query to get an overview of the account, and what
columns I needed would change depending on what looked to be wrong.
It's a lot easier to click on the cell I need and hit copy than to run
another query to narrowing things down.

>> Users dont care about virtual controls or not.
>
> They do. It's the speed issue, esp. on non-win32.

The implementation I did was 4x faster than the old implementation,
which apparently had been acceptable for a long time, but also offered
more features.  There was no tradeoff to that work, unless you had a
phobia of grids. Now you're into trading features for speed.

>> Users care about basic  functionality like being able to copy
>> subsets of data into the  clipboard. Only behing able to copy
>> entire rows at a time is a half  brewn implementation. It would
>> have been much easier for you to  refactor things into a virtual
>> table
>
> Wrong. Look at the current implementation, which basically takes
> version 5021 and *removes* 100 lines of code.

Sticking the new data retrieval code into a virtual table still would
have been less work than ripping out the grid and implementing a
virtual list. Most of the code you removed was there either to
implement the additional clipboard support your code doesn't handle,
or to work around your earlier instance on keeping the retrieval the
same.

> Not quite, I always insisted on doing it "the virtual way" and made
> quite clear that I'd enforce it. Explaining how to do it required more
> work than to do it, I said that earlier. See how it works now, and do
> it with wxGrid if you like.

You said this months ago when I did the initial grid patch:

> Please *dont* try to handle data retrieval different from what it is
> now. We do have the problem of long GUI updates, but we also have
> consistent behaviour on the libpq side, making it comparable to psql
> and so forth. This must remain guaranteed

You refused to clarify when asked what was and wasn't acceptable, and
basically gave the impression that nothing could possibly satisfy you.
So, the only thing that seemed reasonable to do was to disturb as
little code as possible. Hence how we ended up where we're at now.

Ed

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



pgadmin-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Lightspeed for frmQuery and other issues.
Next
From: Andreas Pflug
Date:
Subject: Re: Lightspeed for frmQuery and other issues.