Re: Improve user experience on dropping and re-creating objects

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Evan Martin <postgresql(at)realityexists(dot)net>
Cc: pgadmin-support(at)postgresql(dot)org
Subject: Re: Improve user experience on dropping and re-creating objects
Date: 2011-11-01 10:52:28
Message-ID: 1320144748.2122.25.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgadmin-support by date

  From Date Subject
Next Message Henry Drexler 2011-11-01 16:39:14 Bug, New Column... window, data type typing
Previous Message Guillaume Lelarge 2011-11-01 10:41:17 Re: feature request: displaying components of extension as gray.