Improve user experience on dropping and re-creating objects

From: Evan Martin <postgresql(at)realityexists(dot)net>
To: pgadmin-support(at)postgresql(dot)org
Subject: Improve user experience on dropping and re-creating objects
Date: 2011-11-01 05:11:26
Message-ID: 4EAF7F7E.5020903@realityexists.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Guillaume Lelarge 2011-11-01 10:23:05 Re: very slow when writing query to file
Previous Message Fernando Hevia 2011-10-31 21:26:27 Re: very slow when writing query to file