Re: Improve user experience on dropping and re-creating objects - Mailing list pgadmin-support

From Guillaume Lelarge
Subject Re: Improve user experience on dropping and re-creating objects
Date
Msg-id 1320144748.2122.25.camel@localhost.localdomain
Whole thread Raw
In response to Improve user experience on dropping and re-creating objects  (Evan Martin <postgresql@realityexists.net>)
List pgadmin-support
On Tue, 2011-11-01 at 16:11 +1100, Evan Martin wrote:
> Hi,
> 
> I'm using pgAdmin 1.14.0 on Windows 7 x64 with PostgreSQL 9.1.1. As part 
> of developing my application I regularly drop and re-create the entire 
> schema containing my DB objects. The behaviour of pgAdmin when this 
> happens is confusing to the user and doesn't allow easy recovery:
> 
> 1) If I expand a table's columns (that were not expanded before) no 
> columns are listed and the label says "Columns (0)", misleading. 
> Refreshing seems to have no effect.
> 2) If a table is selected in Object browser when I refresh (by pressing 
> F5) that table disappears and the focus is set to the "Tables" node. All 
> other tables remain.
> 3) Refreshing with the focus on the "Tables" node causes all tables to 
> disappear and the label changes to "Tables (0)".
> 4) Similarly, refreshing on the schema just makes it disappear.
> 5) If an "Edit Data" grid was open refreshing it makes the column labels 
> disappear.
> 

Items 1 to 4 are the normal behaviour of PostgreSQL. We could probably
wonder if the upper object is still there if we found no columns, or no
tables for example.

Item 5 (the Edit Data grid) is a bigger issue, and is something we want
to fix.

> To recover I need to refresh with the focus on either the database node 
> or the "Schemas" node and then manually drill down back to the 
> previously selected node. What I'd like to see happen instead is:
> 
> 1) When refreshing with any Object browser node selected pgAdmin detects 
> that it and its parent have been dropped and refreshes at the 
> appropriate level, eg. if the schema was dropped it should refresh at 
> the "Schemas" level. Alternatively, maybe it should just always refresh 
> the entire database, if there is no major downside to this?

There is a major downside to this: it is horribly slow on some
installations with many objects. So it is quite clear it won't happen.

> 2) When refreshing it should restore the selection back to the same 
> object, if possible. Obviously the "same" object may not exist anymore, 
> but it should make a best effort to select the same type of object with 
> the same name. If it cannot be found then perhaps select the nearest 
> ancestor that can be found.
> 3) When refreshing an edit grid it should similarly try to find the same 
> table/view in the new schema and load data from it. If it cannot be 
> found some kind of unobtrusive message to that effect would be helpful.

Completely agree, but quite difficult with the current implementation.

> 4) Ideally, expanding an object that no longer exists (eg. the columns 
> for a table that has been dropped) should detect this and refresh (at 
> the appropriate level). At minimum, it should give some indication that 
> the object doesn't exist, rather than the misleading impression that it 
> has no children.
> 
> Thanks for considering this and thank you for pgAdmin in general!
> 

Apart from the whole-database-refresh, I quite agree with you. It would
be useful. But it won't be easy to do.


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com



pgadmin-support by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: feature request: displaying components of extension as gray.
Next
From: boris pezzatti
Date:
Subject: Re: very slow when writing query to file