Re: [pgAdmin4][Patch]: RM 1789 Column width of data output panel should fit to data (as pgAdmin III)

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: [pgAdmin4][Patch]: RM 1789 Column width of data output panel should fit to data (as pgAdmin III)
Date: 2016-12-12 10:13:58
Message-ID: CA+OCxoyh7BZr48zAbsK53=cWTPhY1QeL11db=q78s86v8yZ6pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Thanks, patch applied.

On Fri, Dec 9, 2016 at 1:59 PM, Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
wrote:

> Hi Dave
>
> I have tried to get the width of the content but we are sending complete
> data as collection to the SlickGrid. We will have to fetch the content of
> each column and figure out the maximum length for that column by iterating
> all the rows is too expensive. Apart from that to set the width in 'ch' we
> will have to do it using css. With current implementation we are setting
> the column option of the SlickGrid from javascript code.
>
> I have fixed this issue by setting the width of the columns based on data
> type. I have set the width of boolean column to 60, all the
> numeric/integer columns to 80 and for all other data types it is 20% of the
> container width as 33% is too wide. Attached is the patch file, please
> review it and let me know the review comments.
>
> On Fri, Dec 9, 2016 at 2:15 PM, Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>
>> Hi Dave
>>
>> On Fri, Oct 28, 2016 at 8:43 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi <
>>> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>>>
>>>> Hi All
>>>>
>>>> Please find the attached patch to fix the RM #1789 Column width of data
>>>> output panel should fit to data (as pgAdmin III).
>>>>
>>>>
>>> This doesn't seem to work as expected:
>>>
>>> 1) The columns are resized, but equally. For example, given a query of
>>> "SELECT * FROM pg_description", I would expect the first 3 columns to be
>>> roughly the size they are without the patch, and the 4th column to be much
>>> wider (in the ticket I suggested the width of the content, up to a maximum
>>> of 33% of the width of the container).
>>>
>>
>> We will have to set the width of columns depending on the *data type*
>> for example all the numeric/integers we can set the column width = 80(may
>> change), for boolean we can set it up to 50, for strings/timestamps/bytea
>> /jsonb/.. we can set the width equal to 33% of the width of the
>> container. I am not sure how we can find the width of the content. Please
>> suggest is this approach looks good to you?
>>
>>>
>>> 2) After executing a second query (which works as expected), further
>>> queries fail to update the resultset. I was selecting from pg_class,
>>> pg_attribute and pg_description, and repeatedly found (no matter what order
>>> I queried each table), only the first two queries returned the expected
>>> results. The third and subsequent always re-displayed the results of the
>>> second query. Reverting the patch caused this issue to go away.
>>>
>>
>> There was an error in background due to "*forceFitColumns = true*"
>> option of the SlickGrid. I have remove that logic.
>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>>
>> --
>> *Akshay Joshi*
>> *Principal Software Engineer *
>>
>>
>>
>> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246*
>>
>
>
>
> --
> *Akshay Joshi*
> *Principal Software Engineer *
>
>
>
> *Phone: +91 20-3058-9517 <+91%2020%203058%209517>Mobile: +91 976-788-8246*
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2016-12-12 10:31:06 Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Previous Message Dave Page 2016-12-12 10:13:50 pgAdmin 4 commit: Use more sensible column sizes for the data output in