Re: More refresh issues

dpage(at)postgresql(dot)org wrote:
> Erwin Brandstetter wrote:
>> - After deleting an object in the table subtree, the focus jumps back
>> to the table node. Ideally, the focus would go to the the nearest
>> brother object or father node.
>
> OK, now jumps to the parent.

That doesn't seem to work in the table subtree, yet. :/
After deleting ... --> focus goes to ...
... table column --> a random collection node in this table subtree.
... a check or fk constraint --> a unique constraint
... a unique constraint --> the pk constraint
... a trigger --> a table column
... an index --> the colums collection
Other results with other tables. Behavior seems random. In pg 8.1 and pg
8.2 alike.

Also, if deletion fails (because of fk constraint or something) the
focus will still wander. Could this be constricted to successful deletion?
This is not constricted to the table subtree.

(...)
>> - More refresh issues:
>> - After renaming a SEQUENCE, connected tables are out of date.
>
> I think that'll have to stay as it is for now. Refreshing all the
> tables in the database (because it might affect tables in more than
> one schema of course) could be *extremely* expensive. I've seen
> extreme cases where it could take a minute or more to build a tables
> tree as it is :-(

Well, renaming sequences should be a pretty rare thing, not really worth
the trouble. I was only covering it for the sake of completeness.

>> - After renaming a TABLESPACE, all indexes, tables, databases,
>> primary key and unique constraints using are out of date.
>> This actually can have severe side effects. After renaming a
>> tablespace, the combobox "Tablespace" in the properties dialog
>> already uses the new name, but the table still has the old one, so
>> the display defaults to "pg_default". If you use the properties
>> dialog to do anything in such a situation, the table is silently
>> moved to "pg_default". Evil, evil.
>> Maybe it would be a good strategy to perform a refresh on objects
>> right before opening the properties dialog? This would certainly take
>> care of the above situation.
>> I think we have identified most things now, but there may be more.
>> This is a bit of a can of worms. :(
>
> I was able to modify things here to track each object's tablespace by
> OID rather than name. It's still possible to rename a tablespace under
> an open properties dialogue which results in an error, but that
> applies to all sorts of other things as well. In any case, it's
> predictable and well behaved now.

It was the silent side effect that made me uneasy. If people get an
error for these rare cases, that should be just fine. Nothing lost,
nothing broken. So I consider this a proper fix.

>> - A related case:
>> When you refresh any part of the tree manually, changes may turn up,
>> while other objects, which are also affected, keep their obsolete
>> status.
>> If you have a way to probe for changes, this might be easy to catch.
>> Otherwise it may be tricky / expensive. For instance ..
>> .. if you refresh the sequence collection, in theory, you would
>> have to refresh all table objects connected with a sequence.
>> .. if you refresh any part of the table subtree, you would always
>> have to refresh the table as well. (This should be easy, actually.)
>> .. if you refresh the Trigger Functions collections -> all tables
>> with triggers.
>> .. more cases
>> This is an even bigger can of worms. It is probably better to just
>> leave it to the user and not try to cascade manual refreshes.
>
> I'm not convinced there's any sensible way of fixing these issue
> unless we switch to a 'refresh-on-select' type design. That would
> actually allow us to get rid of a fair bit of the code I've written
> over the last few days I imagine, but would be far less bandwidth
> friendly.

Bandwidth friendly is a good thing. And as there is no sure & easy way
to cascade refreshes, leave it to the user.

To sum it up, the policy on refreshing objects in the tree is now:
pgAdmin updates all (well, almost) affected objects after changes made
per dialog. This does not cover changes via manual SQL or from other
users or other clients. I would generally recommend to refresh objects
before working on them in such environments.
Might be worth a note in the help file somewhere.

> Anyhoo, thanks for the bug reports; very precise as usual. We're
> starting to run short on time now so I'm going to call a halt to all
> further behavioural fixes for this release *except* for blatant errors
> or regressions.

I'd say, we have come a long way. :)
Working with object tree and dialogs has become a lot more usable,
reliable and comfortable over the last couple of days. :)

> Usual update for testing is at
> http://developer.pgadmin.org/~dpage/pgadmin3.zip. Please note that
> this was built on my home PC which has a slightly different
> environment than my normal machine. IF you get any dependency errors,
> let me know and I'll whip the laptop out.

Didn't run into any problems.

Regards
Erwin