Обсуждение: [pgAdmin4][Patch]: RM 1789 Column width of data output panel should fit to data (as pgAdmin III)

Поиск
Список
Период
Сортировка

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

От
Akshay Joshi
Дата:
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).

Please review it.

--
Akshay Joshi
Principal Software Engineer 


Phone: +91 20-3058-9517
Mobile: +91 976-788-8246
Вложения
Hi

On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi <akshay.joshi@enterprisedb.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).

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.

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

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

On Fri, Oct 28, 2016 at 8:43 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi <akshay.joshi@enterprisedb.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
Mobile: +91 976-788-8246
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.joshi@enterprisedb.com> wrote:
Hi Dave

On Fri, Oct 28, 2016 at 8:43 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi <akshay.joshi@enterprisedb.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
Mobile: +91 976-788-8246



--
Akshay Joshi
Principal Software Engineer 


Phone: +91 20-3058-9517
Mobile: +91 976-788-8246
Вложения
Thanks, patch applied.

On Fri, Dec 9, 2016 at 1:59 PM, Akshay Joshi <akshay.joshi@enterprisedb.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.joshi@enterprisedb.com> wrote:
Hi Dave

On Fri, Oct 28, 2016 at 8:43 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Fri, Oct 28, 2016 at 7:04 AM, Akshay Joshi <akshay.joshi@enterprisedb.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
Mobile: +91 976-788-8246



--
Akshay Joshi
Principal Software Engineer 


Phone: +91 20-3058-9517
Mobile: +91 976-788-8246



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

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