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

From Evan Martin
Subject Improve user experience on dropping and re-creating objects
Date
Msg-id 4EAF7F7E.5020903@realityexists.net
Whole thread Raw
Responses Re: Improve user experience on dropping and re-creating objects
List pgadmin-support
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.

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?
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.
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!

Regards,

Evan Martin


pgadmin-support by date:

Previous
From: Fernando Hevia
Date:
Subject: Re: very slow when writing query to file
Next
From: Guillaume Lelarge
Date:
Subject: Re: very slow when writing query to file