Re: PATCH: Choose best width for Data Output columns of Query tool

Hi,

On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:

> Hello Dinesh,
>
> DK> Do
> SELECT '1', 'f'; ==>> And then re-size the 1st
> SELECT '1', 'f'; ==>> column to the end of the screen.
> DK> Then do,
> DK> SELECT 'f', '111111......Wide column' ==> This should re-size
> DK> the grid as per the query result, which is not happening currently
> DK> in my windows machine.
> The first column gets same label in both queries
> ("?column?\nunknown"). The original code behaves identically.
>
> DK> Note: Yours 1st patch is working fine with the above case.
> Due to my inadvertence it didn't honour previously saved sizes at all.
>
> Here is another idea:
> Do save the sizes only for those columns which were explicitly
> resized by the user. Every user's resize results in new (or update to
> existing) element in some associative array, whose key is composed of
> colIndex and colLabel, and value is user-specified size. Elements
> never get deleted out of this array for the life of Query window.
> When displaying new result set, each column is inspected, if it's
> index and label have corresponding element in array, it's size is
> restored. Else it falls under automatic sizing.
> Good points here:
> 0. Automatic sizing works by default for every result set - so is
> responsive (unlike last patch!) to changes in query results where
> labels don't change - that's a very frequent case.
> 1. Can save and restore user-specified sizes for columns in several
> _different_ queries (run in the same window in arbitary order).
> 2. Undesired sizing artefacts may appear in rare cases where user has
> manually resized the column AND later he got column with same label
> and in same position but of positively improper size (your last case
> is about it). This still can be overcome by introducing restrictions
> on applying saved sizes ("if saved and auto sizes differ more than n
> times, discard the saved one / resize to something between / etc").
>
> I'll try to implement this approach soon.
> Opinions are welcome!
>
>
This is a good approach. But i am worrying about the performance.

For Ex:-
What if the query is having two many columns in a table, which will be
storing in a Hash/Assoc array, following by a SELECT query with a single
column.

@Dave,

Could you share your inputs on this please.

Thanks,
Dinesh

>
>
>
> Wednesday, November 20, 2013, 12:16:31 PM, you wrote:
>
> DK> Hello,
>
>
> DK> Thanks for fixing this case as per my previous comments.
>
>
> DK> Could you also check one more case with the latest submitted patch.
>
>
> DK> Do
> SELECT '1', 'f'; ==>> And then re-size the 1st
> SELECT '1', 'f'; ==>> column to the end of the screen.
> DK> Then do,
> DK> SELECT 'f', '111111......Wide column' ==> This should re-size
> DK> the grid as per the query result, which is not happening currently
> DK> in my windows machine.
>
>
> DK> Note: Yours 1st patch is working fine with the above case.
>
>
> DK> Thanks for your time and excellent support.
>
>
>
> DK> Dinesh
>
> DK> --
> DK> Dinesh Kumar
> DK> Software Engineer
>
>
> DK> Ph: +918087463317
>
> DK> Skype ID: dinesh.kumar432
>
> DK> www.enterprisedb.com
>
> DK> Follow us on Twitter
> DK> @EnterpriseDB
>
> DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more
>
>
>
>
> DK> On Wed, Nov 20, 2013 at 12:06 PM, Dinesh Kumar
> DK> <dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
> DK> Thanks for fixing.
>
> DK> Let me look into this.
>
>
>
> DK> Dinesh
>
> DK> --
> DK> Dinesh Kumar
> DK> Software Engineer
>
>
> DK> Ph: +918087463317
>
> DK> Skype ID: dinesh.kumar432
>
> DK> www.enterprisedb.com
>
> DK> Follow us on Twitter
> DK> @EnterpriseDB
>
> DK> Visit EnterpriseDB for tutorials, webinars, whitepapers and more
>
>
>
>
>
> DK> On Tue, Nov 19, 2013 at 10:49 PM, J.F. Oster <jinfroster(at)mail(dot)ru>
> wrote:
> DK> Hello Dinesh,
>
> DK>> Could you check the following thing in your development machine.
> >>>> After applying your patch, i am not able to re-size the grid
> >>>> columns in windows 7 (64-bit) machine.
>
> DK> That possibly was a wide column that didn't want to shorten?
> DK> Ok, I changed AutoSizeColumns(bool setAsMin = true) to false.
>
> DP>> please check it retains the column sizes following refresh if the
> DP>> user has customised them,
> DK> I missed this, but now it should work as it did before.
>
> DP>> I would suggest that a column should never take up more than 50%
> DP>> of the visible space, unless that space would otherwise be unused
> DK> That's exactly what is done :)
>
> DK> Please see the modified patch attached.
> DK> Thanks.
>
>
>
>
>
>
>
> DK> Tuesday, November 19, 2013, 4:35:05 PM, you wrote:
>
> DK>> On Tue, Nov 19, 2013 at 2:38 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> DK>> Dinesh, can you review this please? In particular, please check it
> DK>> retains the column sizes following refresh if the user has customised
> DK>> them, and that it puts a limit on the size of very long columns so the
> DK>> user doesn't potentially end up with extremely wide columns that
> DK>> require excessive scrolling (I would suggest that a column should
> DK>> never take up more than 50% of the visible space, unless that space
> DK>> would otherwise be unused (e.g. you have 1 very narrow column, and one
> DK>> large).
>
> DK>> Thanks.
>
> DK>> On Sun, Nov 17, 2013 at 6:41 PM, J.F. Oster <jinfroster(at)mail(dot)ru>
> wrote:
> >>> Hi All,
> >>>
> >>> Please see the attached patch.
> >>> It makes use of wxGrid's AutoSizeColumns() and applies some reasonable
> >>> limits afterwards. Works nicely in most scenarios I could imagine.
> >>> Tested with wxWidgets 2.8.12 on Ubuntu Linux.
> >>>
> >>> Possibly this code should be moved to some procedure and triggered
> >>> from on-resize event handler as well?
> >>> Also it would be nice to have same behavior in "Edit Data" window
> >>> (ctlSQLEditGrid). But I'm new to wxWidgets... so please let me know
> >>> how to implement that better.
> >>> Thanks!
> >>>
> >>>
> >>> P.S. My company is moving from Oracle and a perfect IDE called "PL/SQL
> >>> Developer" (by allroundautomations.com) to PostgreSQL and pgAdmin III.
> >>> Having used pgAdmin years before, I see it gaining functionality to
> >>> support fast-growing PostgreSQL's features (great job!) but not
> >>> usability that well. Hope I can work on that (as far as I can :))
>
>
> --
> Best regards,
> Vadim
>
>