From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Sarah McAlear <smcalear(at)pivotal(dot)io> |
Cc: | Surinder Kumar <surinder(dot)kumar(at)enterprisedb(dot)com>, Shruti B Iyer <siyer(at)pivotal(dot)io>, Robert Eckhardt <reckhardt(at)pivotal(dot)io>, Matthew Kleiman <mkleiman(at)pivotal(dot)io>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>, Joao Pedro De Almeida Pereira <jpereira(at)pivotal(dot)io>, George Gelashvili <ggelashvili(at)pivotal(dot)io> |
Subject: | Re: [pgAdmin4][PATCH] Improvements to Query Results Grid User Experience |
Date: | 2017-06-15 10:32:28 |
Message-ID: | CA+OCxoyhUvggxaD0+QYTb6knB6TA9VP_P2STP+5omkWALoishw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
On Fri, Jun 9, 2017 at 9:03 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Thu, Jun 8, 2017 at 7:31 PM, Sarah McAlear <smcalear(at)pivotal(dot)io> wrote:
>>> Thanks. When I run the tests my browser opens in some default size
>>> that's always consistent, but doesn't match my normal Chrome sessions,
>>> or the 1024x1024 default set in app_starter.py.
>>
>>
>> This looks like an issue with string edit box placement in the
>> implementation. We created an issue for this (RM2477).
>
> That was my guess too.
>
>>> Anyway - I found another issue. If I select one or more columns or
>>> rows, or an arbitrary selection of cells, copy/paste seems to work
>>> fine. However, if I click the Select All arrow, for a small resultset
>>> (e.g. SELECT * FROM pg_database with 18 rows) it works fine, but if I
>>> do the same with the contents of pg_class, which has 1342 rows on this
>>> DB, it seems to fail to populate the clipboard and ends up pasting
>>> whatever was copied previously instead. If I use the Copy button, even
>>> on a fast machine it seems to pause for a second or so before failing
>>> to put the data on the clipboard.
>>
>>
>> We were able to reproduce this with "SELECT generate_series(1, 50000)"
>> The issue was still present for us when we ran the app at each of 2fddf750
>> and 495a3cedb
>> Could we move this discussion to a new thread as it doesn't seem related to
>> these changes?
>
> Something in these changes caused it to start manifesting, but I agree
> the underlying issue was probably there anyway. I'm happy to move to a
> different thread.
I've created a ticket for this: https://redmine.postgresql.org/issues/2489
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2017-06-15 10:40:31 | Re: pgAdmin 4 commit: Use a more sensible name for Query Tool tabs. Fixes # |
Previous Message | Dave Page | 2017-06-15 10:28:23 | Re: Re: Server side cursor limitations for on demand loading of data in query tool [RM2137] [pgAdmin4] |