Re: [pgAdmin4][Patch]: Allow user to cancel long running queries from dashboard - Mailing list pgadmin-hackers

From Shirley Wang
Subject Re: [pgAdmin4][Patch]: Allow user to cancel long running queries from dashboard
Date
Msg-id CAPG3WN4m8MnvKF1OVTj9q85W81znyb1bbRz1QV2fM85bfswTLA@mail.gmail.com
Whole thread Raw
In response to Re: [pgAdmin4][Patch]: Allow user to cancel long running queries from dashboard  (Dave Page <dpage@pgadmin.org>)
List pgadmin-hackers
Ok, I understand that this is a feature that should exist. We should decouple the need for a feature existing from the way the feature is designed and used. I think we need a broader discussion on how to do this.

On Tue, Jul 25, 2017 at 3:59 PM Dave Page <dpage@pgadmin.org> wrote:
On Tue, Jul 25, 2017 at 6:26 AM, Shirley Wang <swang@pivotal.io> wrote:

On Mon, Jul 24, 2017 at 8:11 PM, Dave Page <dpage@pgadmin.org> wrote:


On Mon, Jul 24, 2017 at 3:28 PM, Shirley Wang <swang@pivotal.io> wrote:
2-3 days is a lot of valuable engineering time. Is this a 'drop everything now' kind of feature or can this wait for some user validation on a mock up first? 

Most of the time will likely be on the infrastructure to change the display to a subnode control. If you have some cycles to mockup potential layouts for the subnode view and have them validated, please feel free, however, that seems like an awful lot of work to me to display some missing SQL using a standard control.
Regarding SQL display: Developing simple control to show codemirror in disabled state (for now) wont take that much time.
 
Part of a product designer's job is to make sure there is a definitive need for a feature and that the interface for the feature is designed in such a way that the user gets all intended value from it. Time spent validating now will decrease the time spent later on redesigning / reimplementing.

If everyone is aware of what that value is and confident that how it'll be displayed is right, there's little risk in starting to develop it. If we're wrong, it'll add to feature bloat and detract from the experience.

There are also features that we know are required from nearly 20 years of experience building pgAdmin. This is one of those "D'oh, how on earth did we not think of that" features that should have been in the original release but wasn't. It's painfully obvious that we need this, as a number of users have pointed out since we first released pgAdmin 4. It's the equivalent of a tool for deleting files that doesn't tell you the name of each file.

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

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

pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgAdmin4][Patch]: Handle WSGI Alias while generating URL for endpoints.js
Next
From: Ashesh Vashi
Date:
Subject: pgAdmin 4 commit: Do not dump the session data on the disk on everyreq